From gonzalo.camarillo@ericsson.com Tue Jun 1 07:38:22 2010 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 2ED8828C0F5 for ; Tue, 1 Jun 2010 07:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.208 X-Spam-Level: X-Spam-Status: No, score=-102.208 tagged_above=-999 required=5 tests=[AWL=1.791, BAYES_50=0.001, 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 iKehA3Kax7l8 for ; Tue, 1 Jun 2010 07:38:16 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6427E3A6A20 for ; Tue, 1 Jun 2010 07:38:15 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-a3-4c051b492ec7 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.E4.29106.94B150C4; Tue, 1 Jun 2010 16:38:01 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 16:38:01 +0200 Received: from [131.160.126.212] ([131.160.126.212]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 16:38:00 +0200 Message-ID: <4C051B48.1070909@ericsson.com> Date: Tue, 01 Jun 2010 17:38:00 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Dean Willis References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> <1274663264.1419.6.camel@damnableubu> In-Reply-To: <1274663264.1419.6.camel@damnableubu> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Jun 2010 14:38:00.0838 (UTC) FILETIME=[09083260:01CB0198] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym 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, 01 Jun 2010 14:38:22 -0000 Hi Dean, yes, this is a good one ;o) Cheers, Gonzalo On 24/05/2010 4:07 AM, Dean Willis wrote: > On Thu, 2010-05-20 at 10:17 -0500, Mary Barnes wrote: >> What about SIPALE (SIP ALErting)? >> > > This suggests a variant, also drink related: > > SALUD (Sip ALerting for User Devices) > > "¡salud!" is a proper phrase for a very short toast, meaning "To your > health!". Gonzalo should recognize it.... > > Besides, we're supposed to be multilingual these days, right? > > -- > Dean > From fluffy@cisco.com Tue Jun 1 09:55:30 2010 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 2BBBD28C189 for ; Tue, 1 Jun 2010 09:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.44 X-Spam-Level: X-Spam-Status: No, score=-108.44 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 X5me8TM8JDOV for ; Tue, 1 Jun 2010 09:55:29 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 58C083A693A for ; Tue, 1 Jun 2010 09:55:29 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAfYBEyrR7H+/2dsb2JhbACeNXGoapoMglqCPASDSA X-IronPort-AV: E=Sophos;i="4.53,341,1272844800"; d="scan'208";a="137760264" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2010 16:55:17 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o51GtGOU026034 for ; Tue, 1 Jun 2010 16:55:17 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Tue, 1 Jun 2010 10:55:16 -0600 Message-Id: To: DISPATCH list Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 01 Jun 2010 16:55:30 -0000 I've been talking to a lot of people about the VIPR drafts - here is a = first cut of a proposal for a WG that could do this. I'm sure the = charter proposal needs a bunch of work but I wanted to get the = discussion rolling on the list.=20 Thanks, Cullen=20 (PS - this is sent in my individual contributor role. Take all my posts = about VIPR to be in my individual role not my co-chair role) ------------------------------------------------------- ViPR Charter Proposal (Version 0) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications that = more than a billion people use on a daily basis. They are phone numbers = and DNS rooted address such as web servers and email addresses. The = federation design of SIP is primarily designed for email style addresses = yet a large percentage of SIP deployments primarily use phone numbers = for identifying users. The goal of this working group is to allows = people to use SIP to federate over the the internet while still using = phone numbers to identify the person they wish to communicate with.=20 The VIPR WG will address this problem by developing a peer to peer based = approach to finding SIP domains that claim to be responsible for a given = phone number and the WG will design validation protocols to ensure a = reasonable likelihood that a given domain actually is responsible for = the phone number. One initial validation protocol will be based on a = domain being able to prove it received a particular phone call over the = PSTN based on both sides knowing the start and stop times of that call. = Other validation schemes, such as examining fingerprints or watermarking = of PSTN media, to show that a domain received a particular PSTN phone = call may be considered by the working group. To help mitigate SPAM over = SIP issues, the WG will define an token based authorization scheme so = that domain using SIP to federate can choose to check that incoming SIP = calls are from a domain that successfully validated a phone number.=20 The problem statement and some possible starting points for solutions = are further desired in the following internet drafts which shall form = the bases of the WG documents: draft-rosenberg-dispatch-vipr-overview draft-rosenberg-dispatch-vipr-reload-usage draft-rosenberg-dispatch-vipr-pvp draft-rosenberg-dispatch-vipr-sip-antispam The working group will carefully coordinate with the security area, O&M = area, as well as the appropriate RAI WG including sipcore and p2psip.=20 From mperumal@cisco.com Tue Jun 1 11:12:26 2010 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 2A7823A689B for ; Tue, 1 Jun 2010 11:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.849 X-Spam-Level: X-Spam-Status: No, score=-7.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSc8QkE4rmzr for ; Tue, 1 Jun 2010 11:12:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 47AE23A684E for ; Tue, 1 Jun 2010 11:12:24 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMEAE7qBExAaHtegWdsb2JhbACeMRUBARYiIqhkmhaCWoI8BING X-IronPort-AV: E=Sophos;i="4.53,341,1272844800"; d="scan'208";a="62020481" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-1.cisco.com with ESMTP; 01 Jun 2010 18:12:10 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o51IC8tm027787 for ; Tue, 1 Jun 2010 18:12:09 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 23:42:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jun 2010 23:42:06 +0530 Message-ID: <1D062974A4845E4D8A343C653804920202D4450A@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) Thread-Index: AcsBqzyPXe5Luzl8SjiMmIrGdk/33QAB8ZVw References: From: "Muthu ArulMozhi Perumal (mperumal)" To: "Cullen Jennings (fluffy)" , "DISPATCH list" X-OriginalArrivalTime: 01 Jun 2010 18:12:08.0509 (UTC) FILETIME=[F2D736D0:01CB01B5] Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) 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, 01 Jun 2010 18:12:26 -0000 |The goal of this working group is to allows people to use SIP to |federate over the the internet while still using phone numbers to=20 |identify the person they wish to communicate with. Do we want to use phone numbers as the only way to identify persons or allow people to use phone numbers as one of the ways to identify persons? If it is the later, should we reword "still using phone numbers to identify" as "still allowing phone numbers to identify"? thanks, Muthu =20 |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf |Of Cullen Jennings (fluffy) |Sent: Tuesday, June 01, 2010 10:25 PM |To: DISPATCH list |Subject: [dispatch] Charter Proposal: Verification Involving |PSTNReachability (VIPR) | | |I've been talking to a lot of people about the VIPR drafts - here is a |first cut of a proposal for a WG that could do this. I'm sure the charter |proposal needs a bunch of work but I wanted to get the discussion rolling on |the list. | |Thanks, Cullen | |(PS - this is sent in my individual contributor role. Take all my posts |about VIPR to be in my individual role not my co-chair role) | |------------------------------------------------------- | |ViPR Charter Proposal (Version 0) | |WG Name: Verification Involving PSTN Reachability (VIPR) | |There are two globally deployed address spaces for communications that more |than a billion people use on a daily basis. They are phone numbers and DNS |rooted address such as web servers and email addresses. The federation |design of SIP is primarily designed for email style addresses yet a large |percentage of SIP deployments primarily use phone numbers for identifying |users. The goal of this working group is to allows people to use SIP to |federate over the the internet while still using phone numbers to identify |the person they wish to communicate with. | |The VIPR WG will address this problem by developing a peer to peer based |approach to finding SIP domains that claim to be responsible for a given |phone number and the WG will design validation protocols to ensure a |reasonable likelihood that a given domain actually is responsible for the |phone number. One initial validation protocol will be based on a domain |being able to prove it received a particular phone call over the PSTN based |on both sides knowing the start and stop times of that call. Other |validation schemes, such as examining fingerprints or watermarking of PSTN |media, to show that a domain received a particular PSTN phone call may be |considered by the working group. To help mitigate SPAM over SIP issues, the |WG will define an token based authorization scheme so that domain using SIP |to federate can choose to check that incoming SIP calls are from a domain |that successfully validated a phone number. | |The problem statement and some possible starting points for solutions are |further desired in the following internet drafts which shall form the bases |of the WG documents: |draft-rosenberg-dispatch-vipr-overview |draft-rosenberg-dispatch-vipr-reload-usage |draft-rosenberg-dispatch-vipr-pvp |draft-rosenberg-dispatch-vipr-sip-antispam | |The working group will carefully coordinate with the security area, O&M |area, as well as the appropriate RAI WG including sipcore and p2psip. | | |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From peter.musgrave@magorcorp.com Tue Jun 1 11:29:12 2010 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 52A623A6822 for ; Tue, 1 Jun 2010 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.143 X-Spam-Level: * X-Spam-Status: No, score=1.143 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiUT6FWztvMI for ; Tue, 1 Jun 2010 11:29:08 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D705A3A68B3 for ; Tue, 1 Jun 2010 11:28:37 -0700 (PDT) Received: by gwj19 with SMTP id 19so3980933gwj.31 for ; Tue, 01 Jun 2010 11:28:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.159.11 with SMTP id h11mr6610810ybe.62.1275416897971; Tue, 01 Jun 2010 11:28:17 -0700 (PDT) Received: by 10.150.199.12 with HTTP; Tue, 1 Jun 2010 11:28:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 14:28:17 -0400 Message-ID: From: Peter Musgrave To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 01 Jun 2010 18:29:12 -0000 Hi Cullen, Does the charter need to say anything explicitly about not relying on any of the work which uses ENUMs in DNS as a way of associating SIP endpoints and IP addresses? AFAIK ViPR is about *using* a SIP call to determine a path to the endpoint (however that happens to work). Does the charter need to stipulate that the mapping from a PSTN number to a SIP device is a one-to-one mapping? Does there need to be text about how multiple endpoints which are behind a border device (and all appear as the same PSTN number) are to be handled?. ViPR so far describes an "edge-device" approach. Is the charter restricted to this approach? Thanks, Peter Musgrave On Tue, Jun 1, 2010 at 12:55 PM, Cullen Jennings wrote: > > I've been talking to a lot of people about the VIPR drafts =A0- here is a= first cut of a proposal for a WG that could do this. I'm sure the charter = proposal needs a bunch of work but I wanted to get the discussion rolling o= n the list. > > Thanks, Cullen > > (PS - this is sent in my individual contributor role. Take all my posts a= bout VIPR to be in my individual role not my co-chair role) > > ------------------------------------------------------- > > ViPR Charter Proposal (Version 0) > > WG Name: =A0Verification Involving PSTN Reachability (VIPR) > > There are two globally deployed address spaces for communications that mo= re than a billion people use on a daily basis. They are phone numbers and D= NS rooted address such as web servers and email addresses. The federation d= esign of SIP is primarily designed for email style addresses yet a large pe= rcentage of SIP deployments primarily use phone numbers for identifying use= rs. The goal of this working group is to allows people to use SIP to federa= te over the the internet while still using phone numbers to identify the pe= rson they wish to communicate with. > > The VIPR WG will address this problem by developing a peer to peer based = approach to finding SIP domains that claim to be responsible for a given ph= one number and the WG will design validation protocols to ensure a reasonab= le likelihood that a given domain actually is responsible for the phone num= ber. One initial validation protocol will be based on a domain being able t= o prove it received a particular phone call over the PSTN based on both sid= es knowing the start and stop times of that call. Other validation schemes,= such as examining fingerprints or watermarking of PSTN media, to show that= a domain received a particular PSTN phone call may be considered by the wo= rking group. To help mitigate SPAM over SIP issues, the WG will define an t= oken based authorization scheme so that domain using SIP to federate can ch= oose to check that incoming SIP calls are from a domain that successfully v= alidated a phone number. > > The problem statement and some possible starting points for solutions are= further desired in the following internet drafts which shall form the base= s of the WG documents: > draft-rosenberg-dispatch-vipr-overview > draft-rosenberg-dispatch-vipr-reload-usage > draft-rosenberg-dispatch-vipr-pvp > draft-rosenberg-dispatch-vipr-sip-antispam > > The working group will carefully coordinate with the security area, O&M a= rea, as well as the appropriate RAI WG including sipcore and p2psip. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Tue Jun 1 12:09:11 2010 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 0F60728C103 for ; Tue, 1 Jun 2010 12:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.587 X-Spam-Level: X-Spam-Status: No, score=-8.587 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOCfofGYn1QX for ; Tue, 1 Jun 2010 12:09:09 -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 4838F3A6A25 for ; Tue, 1 Jun 2010 12:09:09 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,341,1272844800"; d="scan'208";a="116974744" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2010 19:08:56 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o51J8uQH020385; Tue, 1 Jun 2010 19:08:56 GMT Message-ID: <4C055AC7.1080308@cisco.com> Date: Tue, 01 Jun 2010 15:08:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Musgrave References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 01 Jun 2010 19:09:11 -0000 Peter Musgrave wrote: > Hi Cullen, > > Does the charter need to say anything explicitly about not relying on > any of the work which uses ENUMs in DNS as a way of associating SIP > endpoints and IP addresses? > > AFAIK ViPR is about *using* a SIP call to determine a path to the > endpoint (however that happens to work). As I understand it, the new WG is about coming up with technique(s) that work and are deployable in the real world. While in principle public ENUM could be used for this, in practice it isn't deployed and so isn't really usable. The technique of using a pstn call to determine the path is one technique that is demonstrably deployable. > Does the charter need to stipulate that the mapping from a PSTN number > to a SIP device is a one-to-one mapping? Does there need to be text > about how multiple endpoints which are behind a border device (and all > appear as the same PSTN number) are to be handled?. IIUC, its likely to be a server responsible for a phone number AOR that will participate in ViPR, rather than individual phone devices. Certainly there can be additional routing after a ViPR call reaches that server. Typically there will only be one of those, or a cooperative cluster of them sharing the same DNS name or ip address. That is really no different than normal sip routing to AORs. Also, AFAIK it doesn't have to be 1:1. Multiple claims can be made for ownership of a phone number. If calls to them can be verified, then they can all be valid candidates for calls to that number. (However, this will logistically be hard to accomplish.) Thanks, Paul > ViPR so far describes an "edge-device" approach. Is the charter > restricted to this approach? > > Thanks, > > Peter Musgrave > > > > On Tue, Jun 1, 2010 at 12:55 PM, Cullen Jennings wrote: >> I've been talking to a lot of people about the VIPR drafts - here is a first cut of a proposal for a WG that could do this. I'm sure the charter proposal needs a bunch of work but I wanted to get the discussion rolling on the list. >> >> Thanks, Cullen >> >> (PS - this is sent in my individual contributor role. Take all my posts about VIPR to be in my individual role not my co-chair role) >> >> ------------------------------------------------------- >> >> ViPR Charter Proposal (Version 0) >> >> WG Name: Verification Involving PSTN Reachability (VIPR) >> >> There are two globally deployed address spaces for communications that more than a billion people use on a daily basis. They are phone numbers and DNS rooted address such as web servers and email addresses. The federation design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments primarily use phone numbers for identifying users. The goal of this working group is to allows people to use SIP to federate over the the internet while still using phone numbers to identify the person they wish to communicate with. >> >> The VIPR WG will address this problem by developing a peer to peer based approach to finding SIP domains that claim to be responsible for a given phone number and the WG will design validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. One initial validation protocol will be based on a domain being able to prove it received a particular phone call over the PSTN based on both sides knowing the start and stop times of that call. Other validation schemes, such as examining fingerprints or watermarking of PSTN media, to show that a domain received a particular PSTN phone call may be considered by the working group. To help mitigate SPAM over SIP issues, the WG will define an token based authorization scheme so that domain using SIP to federate can choose to check that incoming SIP calls are from a domain that successfully validated a phone number. >> >> The problem statement and some possible starting points for solutions are further desired in the following internet drafts which shall form the bases of the WG documents: >> draft-rosenberg-dispatch-vipr-overview >> draft-rosenberg-dispatch-vipr-reload-usage >> draft-rosenberg-dispatch-vipr-pvp >> draft-rosenberg-dispatch-vipr-sip-antispam >> >> The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WG including sipcore and p2psip. >> >> >> _______________________________________________ >> 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 laura.liess.dt@googlemail.com Tue Jun 1 22:54:35 2010 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 91EF23A67B4 for ; Tue, 1 Jun 2010 22:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvVlZAZfnm+a for ; Tue, 1 Jun 2010 22:54:34 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 84F1D3A6A62 for ; Tue, 1 Jun 2010 22:54:17 -0700 (PDT) Received: by wwb39 with SMTP id 39so2448240wwb.31 for ; Tue, 01 Jun 2010 22:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=AiSrZzrsLHjAuD06NFuquLFtxIqLPdZbKZuK1F96Ebk=; b=THgWLmpDEJbWPgCgftXzC+5oi4xWtaPMkGjMzmtsShysqVmBWvV9tn054dQrzELbCT Yf5MAZCNaZYz+V36oefqDIwniYB148KW16r1r3F+u9cTy2BjgPwht6bbHyYYJke3t7ei m3CoHmHNvVqu1lIRTPZagBa10mObuXvYXm2Sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=QTHUg7m09X789Ta8jxe6qvDebRvPv4OKPmvpS9twzb6ahWT8s7LrIt2VeW5gBLSxd8 yDdsmlXSr8muatbbaScPGaNzR9jUWka93QxELwng4VDmjKCi4Vy0WOp+NOZQn7E4tTHA Ocng6z40zHR0pqm0Yw3bJX9yxF9O137XFG/kQ= MIME-Version: 1.0 Received: by 10.216.88.20 with SMTP id z20mr6135234wee.94.1275458039385; Tue, 01 Jun 2010 22:53:59 -0700 (PDT) Received: by 10.216.135.103 with HTTP; Tue, 1 Jun 2010 22:53:59 -0700 (PDT) In-Reply-To: <4C051B48.1070909@ericsson.com> References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> <1274663264.1419.6.camel@damnableubu> <4C051B48.1070909@ericsson.com> Date: Wed, 2 Jun 2010 07:53:59 +0200 Message-ID: From: Laura Liess To: Dean Willis , DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dispatch] Alert Info URNs - Acronym 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, 02 Jun 2010 05:54:35 -0000 This sounds good. Laura 2010/6/1 Gonzalo Camarillo : > Hi Dean, > > yes, this is a good one ;o) > > Cheers, > > Gonzalo > > On 24/05/2010 4:07 AM, Dean Willis wrote: >> On Thu, 2010-05-20 at 10:17 -0500, Mary Barnes wrote: >>> What about SIPALE (SIP ALErting)? >>> >> >> This suggests a variant, also drink related: >> >> SALUD (Sip ALerting for User Devices) >> >> "=A1salud!" is a proper phrase for a very short toast, meaning "To your >> health!". Gonzalo should recognize it.... >> >> Besides, we're supposed to be multilingual these days, right? >> >> -- >> Dean >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From deepanshu@huawei.com Wed Jun 2 00:50:15 2010 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 3605C3A696E for ; Wed, 2 Jun 2010 00:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_93=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 B52ZNxwhO4M4 for ; Wed, 2 Jun 2010 00:50:14 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 216C43A6A28 for ; Wed, 2 Jun 2010 00:50:06 -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 <0L3D00260N2PHP@szxga03-in.huawei.com> for dispatch@ietf.org; Wed, 02 Jun 2010 15:49:38 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3D00181N2P12@szxga03-in.huawei.com> for dispatch@ietf.org; Wed, 02 Jun 2010 15:49:37 +0800 (CST) Received: from D57531 ([10.138.73.32]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3D00846N2LK7@szxml04-in.huawei.com> for dispatch@ietf.org; Wed, 02 Jun 2010 15:49:37 +0800 (CST) Date: Wed, 02 Jun 2010 15:49:33 +0800 From: Deepanshu Gautam In-reply-to: To: 'Cullen Jennings' , 'DISPATCH list' Message-id: <00a301cb0228$23ea82f0$20498a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT Thread-index: AcsBqzuI2pFIkVhXQ1yBzAIcMheHmgAcqk0g Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 07:50:15 -0000 Should there be a set of deliverables what this WG is intending for? Or the draft mentioned are actually the deliverables for this WG. >The goal of this working group is to allows people to use SIP to federate over the the internet while still using phone numbers to identify the person they wish to communicate with. I would suggest to emphasize(for clarity) that the federation being refered here is the *across-domain* federation (although, some wise guys can figure it out with *over the interent* :-)) Does charter have to say that, some extensions(headers, option-tag, ...) to SIP are invisioned e.g for transfering a piece-of-information meant to authorize particular domain to contact a particuar phone number? Regards Deepanshu -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: 2010$BG/(B6$B7n(B2$BF|(B 0:55 To: DISPATCH list Subject: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) I've been talking to a lot of people about the VIPR drafts - here is a first cut of a proposal for a WG that could do this. I'm sure the charter proposal needs a bunch of work but I wanted to get the discussion rolling on the list. Thanks, Cullen (PS - this is sent in my individual contributor role. Take all my posts about VIPR to be in my individual role not my co-chair role) ------------------------------------------------------- ViPR Charter Proposal (Version 0) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications that more than a billion people use on a daily basis. They are phone numbers and DNS rooted address such as web servers and email addresses. The federation design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments primarily use phone numbers for identifying users. The goal of this working group is to allows people to use SIP to federate over the the internet while still using phone numbers to identify the person they wish to communicate with. The VIPR WG will address this problem by developing a peer to peer based approach to finding SIP domains that claim to be responsible for a given phone number and the WG will design validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. One initial validation protocol will be based on a domain being able to prove it received a particular phone call over the PSTN based on both sides knowing the start and stop times of that call. Other validation schemes, such as examining fingerprints or watermarking of PSTN media, to show that a domain received a particular PSTN phone call may be considered by the working group. To help mitigate SPAM over SIP issues, the WG will define an token based authorization scheme so that domain using SIP to federate can choose to check that incoming SIP calls are from a domain that successfully validated a phone number. The problem statement and some possible starting points for solutions are further desired in the following internet drafts which shall form the bases of the WG documents: draft-rosenberg-dispatch-vipr-overview draft-rosenberg-dispatch-vipr-reload-usage draft-rosenberg-dispatch-vipr-pvp draft-rosenberg-dispatch-vipr-sip-antispam The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WG including sipcore and p2psip. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From allyn@cisco.com Wed Jun 2 09:12:42 2010 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 8C0223A6875 for ; Wed, 2 Jun 2010 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPwKxDQYS4Ou for ; Wed, 2 Jun 2010 09:12:23 -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 EE0AE28C110 for ; Wed, 2 Jun 2010 09:12:21 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: Description of Work 2010-06-1.docx : 20278 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAHIfBkyrR7Hu/2dsb2JhbACBP5xccacOmi6CV4I/BIJ+Sg X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="xml'?rels'?docx'72,48?scan'72,48,208,217,72,48";a="331541015" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 02 Jun 2010 16:12:06 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o52GC6ZA027826; Wed, 2 Jun 2010 16:12:06 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 09:12:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AP3S B7oN II+y IUGO JUzR JpJr LPu7 LxJS ORYK QDrr Qb3L TIZU WPMX WfYH XcIW YV3w; 2; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAbQBhAHIAeQAuAGkAZQB0AGYALgBiAGEAcgBuAGUAcwBAAGcAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {34656CA2-D5BC-449D-A32B-D0166DBEE876}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 02 Jun 2010 16:11:59 GMT; VQBwAGQAYQB0AGUAZAAgAGMAaABhAHIAdABlAHIALwB3AG8AcgBrACAAZABlAHMAYwByAGkAcAB0AGkAbwBuACAAZgBvAHIAIAB0AGUAbABlAHAAcgBlAHMAZQBuAGMAZQAgAG0AdQBsAHQAaQAtAHMAdAByAGUAYQBtAHMA MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB026E.58616D6D" x-cr-puzzleid: {34656CA2-D5BC-449D-A32B-D0166DBEE876} Content-class: urn:content-classes:message Date: Wed, 2 Jun 2010 09:11:59 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0176100E@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated charter/work description for telepresence multi-streams Thread-Index: AcsCblSSO/TS3HADTeGaueXI6GRStA== From: "Allyn Romanow (allyn)" To: , , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 02 Jun 2010 16:12:06.0879 (UTC) FILETIME=[58BF6EF0:01CB026E] Subject: [dispatch] Updated charter/work description for telepresence multi-streams 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, 02 Jun 2010 16:12:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB026E.58616D6D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB026E.58616D6D" ------_=_NextPart_002_01CB026E.58616D6D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Here is a version of the work description that addresses the comments made on the first draft.=20 The changes include:=20 1. Charter section, qualification that we are working on SIP-based systems 2. Charter section, minor word smithing 3. Charter section, reference to RAI WG with relevant work 4. Scope section, clarification of interoperability requirements 5. Scope section, replacement of second paragraph regarding treatment of non-video non-audio media types 6. Goals and Milestones - addition of a Problem Statement draft =20 =20 Comments welcome =20 Allyn =20 Multi-streams for Telepresence Description of Work =20 =20 =20 Background One branch of video conferencing has evolved that is focused on immersive "being there" experience. Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments. In recent years telepresence systems have seen considerable market success. Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones. These systems have several important characteristics that are different from more traditional video conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the miking and camera angles at each of the sites . This is distinct from the more traditional approach where the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve immersion. With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating and lighting so that when combined with large high quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is created. Typical video conference systems do not include these considerations. =20 As telepresence video systems have become successful in the market, manufacturers have started exploring delivery of the nonverbal communication and immersive values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, homes and kiosks. These are also telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, and large coordinated multi image displays are available for immersive installations. As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available. =20 Problem Although telepresence systems are based on open standards such as RTP, SIP, H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vendor to another. It would be like having to make sure all parties are on the same equipment (and network) when making a telephone call. A major factor in the inability of Telepresence systems to work with each other is that there is no standard description of the multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio streams sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability to present the remote participants at their true size for their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously providing a spatial audio sound stage consistent with the video presentation. The receiving device that decides how to display the incoming information needs to understand a number of variables such as the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media stream is related to each of the displays, etc.=20 =20 Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify for SIP-based systems the content of media multi-stream messages and the way these will be transported.=20 =20 This work will provide a standard for the exchange of media semantic information that will foster interoperable end stations and conference bridges. It will specify variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability. =20 This requires considering current widely deployed use cases, such as single and multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that are expected to be implemented using the protocol framework produced by this work item. The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technology and may have use cases that are not currently considered. =20 The work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required to be implemented to support this functionality. The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be required. =20 Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and FECframe. =20 Scope The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 =20 The focus of this work is on audio and video multiple streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. =20 Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. =20 =20 =20 The group will produce - Requirements and use cases =20 - Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality required =20 - Specification of a new protocol to support telepresence multi-streams [if required] =20 Goals and Milestones Nov 2010=20 =20 Use Cases and Requirements to IESG as Informational RFC=20 Nov 2010 March 2011=20 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC=20 March 2011 Revise Charter [IF new protocol is not required] Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 =20 =20 ------_=_NextPart_002_01CB026E.58616D6D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

Here is a version of the work description that = addresses the comments made on the first draft.

The changes include:

1.       Charter section, qualification that we are = working on SIP-based systems

2.       Charter section, minor word = smithing

3.       Charter section, reference to RAI WG with = relevant work

4.       Scope section, clarification of interoperability requirements

5.       Scope section, replacement of second paragraph regarding treatment of non-video non-audio media types

6.       Goals and Milestones – addition of a = Problem Statement draft

 

 

Comments welcome

 

Allyn

 

Multi-streams for = Telepresence Description of Work

 

 

 

Background

One branch of video conferencing has evolved that is focused on immersive “being there” experience.  Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were mainly = research projects or business systems with limited deployments.  In recent = years telepresence systems have seen considerable market success.  = Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with = multiple relatively large displays permitting life size image reproduction, = multiple cameras, encoders, decoders and microphones.  These systems have = several important characteristics that are different from more traditional video conferencing systems. 

 

The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, seating = order and spatial audio by carefully orchestrating the miking and camera angles at = each of the sites . This is distinct from the more traditional approach where = the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics.  =

 

A = second difference is manipulation of the environment to improve = immersion.  With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating = and lighting so that when combined with large high quality displays, a = strong sense of a "trompe l'oeil" or "being there" immersive = experience is created.  Typical video conference systems do not include these considerations.

 

As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal communication and = immersive values of telepresence via smaller, less expensive and more flexible = video conferencing systems for a variety of venues, such as individual = offices, homes and kiosks. These are also  telepresence systems, since the audio = and video quality is high enough to allow clear image reproduction for = nonverbal communication, they are able to send and receive multiple media streams, = and large coordinated multi image displays are available for immersive installations.   As the industry develops, the line between = telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available.

 

Problem<= /p>

Although telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one = vendor to another. It would be like having to make sure all parties are on the = same equipment (and network) when making a telephone call.  A major = factor in the inability of Telepresence systems to work with each other is that = there is no standard description of the multiple streams that comprise the media = flows.

 

For example, in a multiple screen conference, the video and audio streams sent from = remote participants must be understood by receivers so that they can be = presented in a coherent and life-like manner. This includes the ability to present the = remote participants at their true size for their apparent distance, while = maintaining correct eye contact, gesticular cues, and simultaneously providing a = spatial audio sound stage consistent with the video presentation.  The = receiving device that decides how to display the incoming information needs to = understand a number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is related to = each of the displays, etc.

 

Charter<= /p>

The Telepresence Multi-Streams work item in DISPATCH is chartered to define = and specify for SIP-based systems the content of media multi-stream messages = and the way these will be transported.

 

This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference bridges. = It will specify  = variables that describe the semantics of the media streams and the recommended behavior = to achieve interoperability. 

 

This requires considering current widely deployed use cases, such as single = and multiple screens, multi-point, Scalable Video Coding (SVC), as well as = cases that are expected to be implemented using the protocol framework = produced by this work item.  The methodology for describing the variables must = allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently = considered.

 

The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media streams, = including a specification of variables required to support the use cases. This = work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality.  The document will = identify any enhancements required to existing protocols as well as describing = new protocol(s) for interoperable multi-streams negotiation that may be = required.

 

Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe.

 

Scope

The scope includes both systems that provide a fully immersive experience, and = systems that interwork with them and therefore need to understand the same = multiple stream semantics.

 

 

The focus of this work is on audio and video multiple streams.  Other = media types may be considered, however development of methodologies for them = is not within the scope of this work.

 

Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems.  However, backwards compatibility with = existing non-standards compliant telepresence systems is not = required.

 

 

 

The group will produce

- Requirements and use cases

 

- Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing protocol = enhancements and new protocol functionality required

 

- Specification of a new protocol to support telepresence multi-streams = [if required]

 

Goals and Milestones

Nov 2010

 

Use Cases and Requirements to IESG as Informational RFC

Nov 2010

March 2011

Problem Statement to IESG as Informational RFC

Architecture to IESG as Informational RFC

March 2011

Revise Charter [IF new protocol is not required]

Nov 2011

Submit protocol draft to IESG as Proposed Standard RFC

 

 

 

------_=_NextPart_002_01CB026E.58616D6D-- ------_=_NextPart_001_01CB026E.58616D6D Content-Type: application/octet-stream; name="Description of Work 2010-06-1.docx" Content-Transfer-Encoding: base64 Content-Description: Description of Work 2010-06-1.docx Content-Disposition: attachment; filename="Description of Work 2010-06-1.docx" UEsDBBQABgAIAAAAIQAwySgMcgEAAKUFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMluwjAQvVfqP0S+Vomhh6qqCBy6HFuk0g8w9gSsepPHbH/fSaBR1UKQClwiJeO3+OXZg9HammwJ EbV3JesXPZaBk15pNyvZx+Qlv2cZJuGUMN5ByTaAbDS8vhpMNgEwI7TDks1TCg+co5yDFVj4AI4m lY9WJHqNMx6E/BQz4Le93h2X3iVwKU81BxsOnqASC5Oy5zV93jqJYJBlj9uFtVbJRAhGS5HIKV86 9Usl3ykUhGzW4FwHvCEbjO9VqCeHBXa4N4omagXZWMT0KizZ4CsfFVdeLiztoeim2ePTV5WW0OJr thC9BETK3JqinVih3bf/gz7cwk4hEvL8RlrqoyYwbQzg+R1sebvkKaxx9AE5leNkfajrp0Dl9D8C xKSh7c/B/BFSovQvsfkdc9f2myomOnTAm2f/5AwamqOSFZ3LiZgaOFnvT/1b6qMmVjB9v1j6P8i7 jLT9kz7+I4zvO6tG72kdby7Z4RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03 Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1 nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQCzvosdCQEAALYD AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKyTz0rEMBDG74LvEOZu0666iGy6FxH2qvUB0nb6B5ukJLNq396hsNsuLvXS S2C+kO/7zTDZ7X9MJ77Qh9ZZBUkUg0BbuLK1tYKP7PXuCUQgbUvdOYsKBgywT29vdm/YaeJHoWn7 INjFBgUNUf8sZSgaNDpErkfLN5XzRhOXvpa9Lj51jXITx1vp5x6QXniKQ6nAH8p7ENnQc/L/3q6q 2gJfXHE0aOlKhAxIxJ0F9tS+RlJwUiLmBHkdYbMqAg0dz3ACGOul+GTNeHs0OXqewURwlpYgtmtC EK8HTgBjKcczWWJ4XJOhcpYynXczjrO0BPGwJsQ35u9/VnImnkDkxW9LfwEAAP//AwBQSwMEFAAG AAgAAAAhACtqkkmTGAAAdpMAABEAAAB3b3JkL2RvY3VtZW50LnhtbOxd227jyBF9D5B/IPSSXcAX 2ZZHHiOjQJblXQOZ3YHt3Q0Q5IEiWxbXJJvhRRrtUz4kAfIt+ZR8SU5Vsyk2TdryWLRHkwF27bF4 K3bX5dSp6tYf//Qx8K25iBNPhu86B3vdjiVCR7peePuu89PNxe5Jx0pSO3RtX4biXWcpks6fBr// 3R8Xp650skCEqYVbhMnpHEdnaRqd7u8nzkwEdrInIxHi4FTGgZ3iz/h2P7DjuyzadWQQ2ak38Xwv Xe4fdrtvOvlt5LtOFoen+S12A8+JZSKnKV1yKqdTzxH5L31FvM5z1ZXnucj8xP1Y+JBBhsnMixJ9 t+BT74ZXnOmbzB96iXng6/MW0TpPc2N7gfkIfCX2QsZuFEtHJAk+PVcHizsedB96dj6AdIviinVE MJ+pJQlsLyxuQ9pRmf9i8vYwefvq2ft0q9WLYCwG0KWJdJf0O7IWp9BF9+pdp9sdn/SOzkYd/dEH THS3e/L2cDgeFx+ei6md+SkdOTs66HWP+XbRh5ju9quDa+e2/67jQE9F3NmnT2N1ML6QYZrgBDtx PO9dZxh7NiZmcTobhknxN18xUT9HCX7v5zfA7/wpca2Am3vS4pRN7DSJbAdjHMUiEfFcdAbv8eLe bpLGwg4SC1Zm3Qhf8PHQERaJmiqBWRgtJo3Vxdlx7wKmnY+2MbQblXxwLhIn9iKyM0tOrV9kfGcI RuNITzRnvn/UHQ/rxdMyl2Z+rE7n27zczH9hkp8Pj9+MG1SiZszN0z+QUnVPjkejg7IBbtbUagfc lOPK0OTPQ2zYmBbEkG6zdnZmO3e3scxC93Hzesj6tagl8zJPV1N9dDzqPWuqMZmsHTSpuUPWj372 KOl7k//7MRTWJLZDZ0buZ+65QlqODKciBs5B/LRmdmKJufTnwhy50rSRcg/f9s4OGoLRp8xkSUZC Pve9u5XO7NSYy5JEmxyihsd7FFKcLBGuBdftBQGBxLmw/vuPf04EDVw6wxj+9x//ssTHSMQehlPs /eff1pXA2Ma4KpWWF1pzO/ZkhjhrLxMryTANGO+5F6eZ7RsTsVMNWMA4cjqOyXjSZYTIl0TC969T O07zQN6KwqSlGFoZ/nqJxqHbojwNs4NgHwjXsy1GBcmOJezYX1rJMkkFwMACU2MRPMNnhBfsGAMP 8X8VDjAPLq68WeGhSNXf9PvDUa8++j5T1QeTDKAVyLXp+S+g2MUYeenM8r3AS6Gsroh8uaR0JiEl vgwxbAQarSXGLqkOV70ifFVNQqWFDs5seItEiJDMHJhexPbEfxiWtqh59XZE6ahIq9NbWEP72giP SIkc6dyF9H1JiR55ViuQrvApZBmGvcPHpl6cpPCoGF+cgNwKvtlB9mIO/YSGHp7Tc2wfbsCXjk2a Dp8MR0qn40NXJN5tiE8plfTFbpTFkUyEBddLXoQsJKAsI8LEqXR5LuhednwrLNdLIp/cOtw/rCgl 0X1vikn3fhOIGDbOiZGPSDdzCP/vrO7l2BDZJrdFZAMiyw5EUf+yQDZYnDlGM1AOPDQ3M/gw8+0S AdYCr+wFkYxBUKSWM7Nj20Ga5yWp5yQcPy0bftD1phzuU2saywAji8/S2HY9Egq3qAEFuY+gaTE8 FaEVTjN06HksmdLnvTSc2oSgx6PD8+6hjgPbhfvqzR16ZCnj0TqBPBneyRFxmNA/0hhGqE1w7iUE UuaeWETSg4bBdEBeiJihTQDFhgFGgCOe40WkgaEMoZQTXEM2mYWwPFKxPcvU3yjP4C0YPkIMGS4h 9wgRXbARVTVZwyaxZGlTaPlOfsmtSNIM99uBp8XDYIFKQjIiQAO+uZ25nrQmS8uBNUwzsnsJPIAr Y3UJ+RtDzaHla4MvsoDxOZgaUHhAqETebNJtDgLvDq+1lnj3kVjLwtVrGXsw9nAVqYu4QmL1Tvr9 45ZQlv3Qg1ucrMbxQGxJLDtFMFN5GGlcAuB1D1kVQ7RJHaoXa6+q88WzH3PqzwTB9eLczJBx4b+m qdvkgAwQuuEsHBURm574KsOQg59KiLYjOCTSnQUlnXzOrZCBSGPPyYGJ4vGtiUgXBHzy7CgnRzGu oUwtzmaRlxYeGF5dxDmFajptpKlASUiWapwvG7hy2e4ytAFWGKUY47iJAPwixMvWCNoS/TEYInQi 9CMHzHEiMAH0JbBDL8pUhYhgNrksEYK5kCFXvYjeyDEAkyPG7JdkJSs6Ougen7cUH6ly1/TsTfqM eq9FCPkXShMqIqyPHzYp42A7yJs8u9ixQECiUJrK29iOZvBk2udA3SrjacSm/tHxeW9VA9vkCNbP cg1ALATa5NMHlKT6hpmVE0jO5lYgFslnSLkrApkPiAvs60hfxsiRmWhIZnYkVriYELHv3c4YJCdS pYcIJ0RPBBNMhKvyXZXbznCm9XfAf9Sni0R3xwLfhhQBTwJwR0aKebKtTmWqXkv1kdtGYi1Z7uPk TU5ivQpVFfqVRsn/gxSe/xmM0qCDJMzqlKj0TolkX1HqFIocVHhB3ZCvvVF8TpWzWJEjrmSko2yC kRL0tCDgKB1N9ozX35r4vzWCloJ/+3Y1vJcxvJJlbUfoVVyfLgEwRT0B+gtgQIqJBT9CPA9FPEUO g7W0w2wKzgU8C0oBitamKhQiBuwUEYdCD9haVMdiUCsKKjZwQZw6rIppaE7JkATfj/dfJxE9IQ19 L3B+iMMBCGyBYA9mAQVclCBRYwAfx+wxMbxTX3z0qODQTO9yz4zNJUqBMI9ZmIsQ8wHQkBcqvdD1 cD3RgKp9Ccdm0BaQGYATd55M7hJN7xHVbPtAFp9JqNsOg8xN0QhJJQfadva00/Tg9j031VyQapKn UQwtqZRSVg08EfsZiIpQZsCjSDmh9HJhOT6qQjUVFlboBs/DpaMlQ2iGx7gZQKzLiky1TjKeotZj sCeAvYSduebjSPDLXsiVJD47l6KoBbEVzG3P54dQU9rK23khWkn9vOkSaAZ4BuGLBgB2lgFZU0EK BSYZNdaHv2R9oIFA8QH9KjmHVdHNrzHhgZiwMh6AXS73Ibm+RexeYjg5wE/8jPtS0H/SYCKs5w3q WtwFPKSLCoqtdfxF0PR43D04Gz+ntQ7o2ei3qkXTB0f9N/2LTm0dR39YqmSeoPLTK3qiuED4fEHR DPwibbZ6QKhJ7EMsgRQCw95qB8hkZM1CV80AmadvboBa70QuDU59Oj/00xnHJGPMnlo3fEjfnllk 2QQVSMGmRRHrR7aKHlsh2uofrdMiiuETO+/8q0xwIQ4PTr93MWzwF8+cv3oJaUXJaw4Qr4SJ3VVV 6Ormw451fYkf3+8dvul9Lk2M3+8dHR5VZq4ePrwKF5hkqP3mgNQBiYvSnLATD2GVC3KYZXQmCMXH qpIxsBE0D4UGmaWWOg5oaWMJDK1OAoym+F/KAt2iu0f8PfMiVbFBQy01/oQJIChSOO4GQosRZX0u 7kbwGqLgSQ+Xhsdnh0fDl6TfL9HsJTPfbdR8ssX2pPLtJL3CEKHy6n5AU9cZ6Mg7XhKTDiYEWe8E sSIEtzCEgY0/E3AllKuo9hhKl/E32ogJ4ibo/bJWs/INzVwIxIuVId9SfRe1W5taPkCtcwpLXWBo XfF9E2mVksRn52rAHEZIbaYeKjZVeMNni/BoxLWGGJdfoaZERVFapUYTuZhaRUf0xU2pd7lol8Oc NEndrt400Dc00fdMu0nC9scVOTZ12pNqQkfxV4jEOPfz1B9ZXr1E6lvkyHrhFV+NDCNC46FK51X2 PEWmDnLIeLPPFlRq9SMBaTnGZyto1VS1wK/iDi5gh+KjHaA9docM0i5pB4o2XFvMk1EV7nJ+h1ye 4ny0ElEjoApIsQgkYl+prxC9CCBHkIBaGTnhJJXSpXa+nLUBJ63LmdBP6vIL6VzucUF7C3f82igB kX7jIfRs6tLdZb8NbjukeKe6j7iQCm9Neq7dCtxHfiv+uE48ZT0eImicwb9T9y8RP7gLPkPrDpw/ Hkw9RxSqd+DkPfCytDwhxf/k6h2J1BztSEaHo2E5T0ktnu00qkpGOSJ1WnoOGkLiteRqAVfVSFWP ki2HSWya6cQjf2WHAmtwAK+AAcEwquBqtocmtHSMHB+atrlciIUkmDRuASd1UMRkrgl5Wyv1teZa SLcEd4fV2abDK5klBZtNr6KqGZLBQ+um2gh4NTI0TEtFcTYHHtYWAU32WIgBVhkkMgw7Z23ZsEFG y4Cm0QthvOhKQakYuEwg2cGZuedhx2WFWTABHKd6CVZ3EdG7SohIV7RmYSkB99jTmepzAEeq2dAf U08A0dI90F+tzyjWBdAZ6g/rN6xFYJ+B9r8yL02xmtckwMVBwnJrqWajsb4gdb6oEPwQyq8hoL4Y hm6ExR1o1TQsaB2MUmIrt5aMW9u6b2A0RgrwnncIuM6bYBl4I/EOCKqcX15/GN6Mvuf+EjW4yo5c MaUaBAcPWic0XT7o0d8M3xz2FTPN/DIc/hM2Vlgv6yIwAY5lV3FSmqUydKEUZ9qI/vUOnZ0UFo1Q oIQjU86J8wPdUoxKcYKIqsrFdDqWwZL3Q6Kw8JAeA6cxIRFhDRMafMyRrtXvfLy1rRsvqz8sKb15 essMdK3AvWPsNnHU0bI9JnCNlb59e3BweFIufthZKq9pO4zzMe7LO3x01Rrc1ZEfqkfcX4Gir6gD 8BJIx7zsSaqLa53kXWckM6x6jq0fxIKejZc3CiyvopEM49nOm6yDENBmbXbAmqyQZbX/8BUgDvdo wnvZsauzEORoWFIVAtkWVpqg7xZLrxwD7XAmz28zlYC/xLHgJ7ON1EgiFEDmHjr2j0WlkbYY8FzY ecWCSzrwnHF/WOEaySrQhk1aYFjhk5n6T5SHR5bXniKmlKAjD7tiWsgfwkvq2eHOKPqgjPtWzhQp I619RVKMfFgQBUlZJ1hcZ+ahj6A8fbzR1F6lNWcT/sp0b+xgt9Nf1Q6G6Y0/pd65nYNRMtxXMRX2 4zGR5FjbWbTvMlNCTQycmLu0ElvtWwD9x9ImJExJuXmtyfg3noh/oj9Qa87Zk65IVabN0GXXJPyr TIfCdLwIuFmylx/WwTXKItxn9TPvazPiffusb15p7AbXP4+aHv0Kg/NtkyyvokJooqNtWYD58ZsN FZEOxCkVxqhuiY0LmMZABMSyMjSjwMjZrMnoKQQCYKUSC1zAEqOAxhgPH2FrBQp+lFSADikyPES6 Gw6bKJi6WBRzu2QslAdZfcsVe8MEs+otFB+RzyT51oyalynORGssdy1WxhaSvMhePY96mgGXDGmB PZjmtYQcb3j7nkdFrM8lKQ8HwUz6YS3BxWLShTML1dxRMk6dbNx7Xnj6lQJRAd1RgQExQa/2QEJp jEBLEX4j274ZRAAJum4RqpTrmmCFodj5Sf+wd/h/mzo+qosD8hKF11CcBEIJMiNA9ELRaHMWJoVy REK+CSGatFKzRUDo5GqqXoZOKQiOKrlsT6iZowj9Bsancppe1UebXBERlW+nQT6p8EdggBkkse9M soiIFHaXhfB5bavyktpG+NxY0Nm4LVYM0Lr4W+tyfHNReFyVcOTOFm8Nn40EA+ZJK0L2a/xysTNu xd/qU4m3Xkld8fjIX1bvAacwzbBOH1w8L0XM/XrxAE6pigmzwyWSVGS6DocP8zHFu62kKEWkkqQh 6Hh9zjfJtzylZiJcprhQLxe3EvuMcL2AQ5rquS3ecQ0nZLJUVyWbNo9ssU3XOl/z7R5Nr8zTt3gw kF69FOlwhZaYOW3Oww4AxgVzc7FncmhlEQpctPsjb5TlUpcReHEjYq5TdN78iwz+Mvrxh7XkWGGX zUtRD1PupT/wFI8gv82LNnj//qfry2quUS/JawzR8OcbFR3XmsTr0o6WLYzVxXjEGcNasrQ5WoM1 AsHzd/PdTsRXGx2eOBg1td7tGAzUN9usn9SDYPOh1OBz7YDpN6xkE7NiTqKK2WqnbbJ1vfVxvgPy upVTCNZarUnfe3H6UN8v5Q0JDViO08FSTtA6vWo6JW4DHpnahpDRql3nVkuriPFQWwYrR6lruowf GWxyuNbdRwHnGmBBsH8dre2ltpRKVwoOqs7iIp9QrXWrWsLLuJ+Nz22tEppI8DHAfE+mVZX0Neqn NcZe+5L9fvcIm4zDfku7ClY+LKUK5hG2tPyjkqVF1+kSpby8+vvBR//hDRgvVTxmm8LT1jLD3K0M +WsjuBs++U3f97Cnbpj8NgIppwrU6jNtXfTCtduel0R+QXHI/5FJ847fivQr6EQU4ZDy8h6SlM6r RsCKlaHwaf1I9plX6mjDbtpCixZflvgoWjy/oI1bqVeQ1vnyugwuymqi0sN1efMo+lTUtm3kBvJ2 d+VzcEXBd65h1qZmlK3FPNLgnbfDWiouwSC5oYNsQiVrMU/fljfHezwZIpfcTXOpvCj0M43BcUcv AqD6Gxh5j5JIHaegmJrCWW0WsWpRUjZStAcQo5RfCTv5XpnADpbYOXcLtCmoB4BAyRdy8NMLugZr ldFNBMsrzlSiGEillUTVHLjnMOutzJkeUu0l9ISs4RBMUPYo72Kevi22UhtTzVf5Et48j8OVbiwT 3utoWzskZtng0SExT2dl2EQFhLeu01ih2+13R9zRBokZBmzBG7SaxDHAKj9BIxa1DatuQaNyqOEY W5rxs7dHhydvv9aVajsgaWp2rStV4uBaEadvRUXm6wQ19Yx+1VbAO+3q4Pk0bjXA7JPBRH2EwGPY syptHa5Ketjr66JosSjVxYhh0HWxFfwjGuIpFTw2BV2xI2BYAD19b7OERylXuSJn1gMLFPrVpr7a 1Es2pT9qU/Xlo13rulrKt031LpW/DZ1eJ8N5KXextT1GZuH+r9608B9/Mwa7pTj0fJysnbaOEZ+t oCr/wM/axqaNhbYCFlefRFHtO4ntKDnevMd6aywbx7cp1U5zOvEpqOKXoiTxj19gSws0bRL7qr59 j1gwxWri8Ii+iQ8LcCiA8YkHx6sz3Y+2ceJ7m0mbVNJ3vOKmtef6YooafeNhFBdSfHdT8wkxLexp PA49yaXWwkz8P0uJfSjy1UPdoU63yqPwHVZ10Mjc4vcIrZfq8b2TY/V+xsfH/TelW+gr0wLDUAes mTvWppo3/C3Hpfwi1ShlvVGnN9VXODyrTj6pTj6nB71eaVqLyZoPsTt6qAfEofZT/sJkumF+C+M7 etd4lzLTap6+obQZsvG74nc9m55/W/STIaNJfdXHsh/k3DrsHnTNlhEShTFsmo9+7Rwc92uN4Klz cHjYf3tefENXebjNIy0Nt3pXvDC0hvll0nHzybU6Xhb0y9OLn9BLOKKVGOx6jTQY4MZwwC8HakyF HlyOr79bS5JVQ4ie4+flYqYc9YZFHfKXq00IkI9dXYzMgTOsDH+kKsJ8sc62YlSlOo55pCVDh3k/ 04UOtLc0tK7WgZge4f/QgQCiYKsLhJaDB5SeovKnhpb/CQAAAP//7FfbbqMwEP0Vix8oIUlzUYOU klDlYVdRslIfVvtgwIAlg1ljQrtfv2MDSVFplc1FWlV5Al9mGM7czswMn6SSCOPOfrgrp9JfC/uh nGaonIqcBpuZYZqWNZosLKPZWpAQF0y+P1mrLXM8dJyeoZVUukT9cHkqc1CCc5/SmTEXFDOlNJ6n +X5dmaFFwJysFlXaTlUDP4VeEjbNM+yTmZEJkhOxI4a9FtxjJEFbiSVJAAUkOdIgaCgqHATn4VII MFO+ZiCeZ4QxkBBSIQZWnWmavVpun4766DINLvPJbjQQztEqDblIsKQ8xQxtXKdlmPKHdmsTCMrd 7uNw4I73sbEWanM8sebL5X7zTcC0r18vYBoTW/ac6apu3ObCj6kkviwEOSmArmHqKVF1DTu6IesM tXbmVbGmC1JVl3SeSZWH+7LUjqVNy9X1vR86HB8nfWs80SVJ1lVEesxRiQw1gaYR3C5nRm+oIrZK 8+AFNxWxkfBV+DT1UfrPtdBgYL4TK6e7OaNRCld2mB1TYo/4l80XSSP7G4aUQZbZ63WUl9rlCulO vIejDjfd8P6ohwKO9obsaE6QE0PTIgL9XLkoJSXKBJfc5wzRHKVcIkF+F1SQ4NfHXlHOuSXiV0nE 7uL8ne90bn5Sj2/JeeA4V+EU28JLqDxkaCBweBo7hQ6k+2WrOZ5p8/9PLoDZZzwngaL2aYBFoLjs JwFd1zX18JhCpzX+nN+b3XtzuOhrAtJMNGfORGDqpbi4/t/LTGqNVTnQ4fW/crUtCKnhYbSwHNOs wIq2f2qaZVkVz4oVTxvDu56+sgjIBNyQPIP9mooJGsWgqVl6XEqeHNaMhG9OY4IDAixxZGkaF3IO PXK/jAqpl/XnoFuqAbaeJJWItiLg/pOgAZwwmpI1lT5Y2b/XpwBJhYamsR4PXvULiBRq5LT/AgAA //8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZ T2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbY pfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72 L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ +AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW 9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2Bq Htfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i1 2mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8 hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0P UwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rD J7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KK zSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZ eThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+ VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKY lQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfC cVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxHal1CqnQoc0+Tv yjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2vuVt4kuwRCPP5jeddyX1X cr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWmaZAn7RNCHQb3OnA5JcWJKI3jM6rqD CwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd2WNhUx8YbD2QWO3ywA6v6OH8XFCQ MbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3DrVAZfDivGgwW1oQGBEHbAlZehfO5Zg0H E8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA2KnwkT7knWK1EreWJvsG3M7ipDK7xgJ2 uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp2xvDmRYe4xS8LnXPh1kIF0O+EjbsT01mk+Uz b7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8y00w60UpYCP9NaRYWYNg+NekADu6riXj MfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQJ6ASriZMRdAvcI+mrW2m3OKcJV359srg7Dhm aYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+KSfkLUqUcxv8zVfR+AjcFK4H2gA/XuAIjna9tjwsV cahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU/23OWRomreHAp/ZpiASF/UhFgpA9KEsm+k4hVs/2 LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjUTU4535waUuy9Ngf+6c7H JjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5t1pbseY0Xm7mwoEX5zWG waIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAEjZMdtMGkSVnTZq2Ttlq+ WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5QcY4xnzSKn914qN74Ogt uN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAAACEAMD2VnY4FAAA2EgAA EQAAAHdvcmQvc2V0dGluZ3MueG1snFjbjts2EH0v0H8w/Nxd807JyCbQjW2KpA3i5ANoiV4LK4mC RK+z/fqObCveRWeDoE+W5s7hGVLHb959a5vFoxvG2nd3S3pLlgvXlb6qu/u75dcv5iZaLsZgu8o2 vnN3yyc3Lt+9/fWXN8f16EIAs3EBIbpx7e+Wh6Fbj+XetXa8aety8KPfhZvSt2u/29Wlu/wsLx7D 3XIfQr9erS5Ot753HUTb+aG1Ybz1w/3q7Jn78tC6LqwYIWo1uMYGKHjc1/04R2v/bzRItZ+DPP5o EY9tM9sdKfmR5WW5Rz9U3z1+przJoR986cYROts25+W2tu7mMGPzM3HO/fxQbwc7PD0L8ha27R/v 28Vx3buhhIbCnhOyXE0KSOx3m2CDA/XYu6Y5gaBsnO3OFmGw5cNn91hPaBlPTpXb2UMTvtjtJvge HB8tVKjZJWa5t+AT3LDpbQnhMt+FwTezXeX/8iHzbT/Ais85AC29DafYAMpqnCqbHj57H2Y3Qkgk s4yePSbtMw2XmcA1ihciQX1ejxYpLQzqE+u8yFFNRvI4xjVcxhGqKWhWcFRjmGCoD+VaabQ2KgnN cR9YTYL7aK1lgVVAI5KSFNXk3DCGagpaRBLTMEKVRLvDKNEZ2gPGdJyjeViuGL4LrGA8uqDwJUJY oQhFEcKJVDHqwymRucLWw6mMX/Hhkmg8miDKoNjhUkUK7QGPNEAErSDlEd5rnukE74GQxKRoHqG5 IALLI7SI8wzVRIAd3CfRpEBnTqSC4nsqMsk5nsdQmqK4FobGMYprKZnRKBKlAiSi+yMzlhMUb4oy IlHsKABPhlagtE4ytDsqUUyje6pyYQg6JcqIrEB7oIxKcnRONZe5QPNoTTh+WuqE5wbtjk4JzTSG A52DAsW1zlk23zMvp1Eb8EIREhFSCBQHEec0RfcniriJcU3MkgLtQZTQlKOzHWVEMXRPYyYUjqoY AEfQPHFMKX6Sx1BbiqIqLgRMN9brhDFhUIQksUgp2rckkSk+P0kqieBYnpSKTKDdSRmTGYqQlCkd 4z6cCiLRPJxJfOrTiGqKrjSNOYte0ciIo7OQxtpQvOqEqRTduTQjLMG7U7DolQoKCRcNttIMbgV8 fjIqeYTOT8Z0RNH1ZFzlEs8jKFyBaAURjyh6ImXQA25Qn1zoFM9TCErRvuVaGolWnUcaPmuwPHki FX6+5ang+OlSSPXKGQKaV+65QvNXbqYiEjxF56eImcpRHBQp4wnagyIHVOE+OTP4vVDkUAHa66Ig FMeoEYxq9Bw1UmT4SW6kUhrdH6Pgewet2sBFZ1CEGC3SHJ0sOJJ1jOLNpHDIo3eJSaUwKHqNmb/s VmdqAByhXU8s7tMwPxngGYv2TEYy226H2i4+TjwPiEW73g4Pad3N+q0DvumeazaH7ay8uTkrxtY2 jQEuMyuA4p01VT32ududAjcf7XB/jXxqRrseUCkwpz+/R5uomBt+H/yhP0c9DrZ/31UgnhNSIS7x 6i58qNtZPh62m9mrA7r3THXoqr8fhyng6tqg4zoAQ3dThz7Y7n5mTq67+bqZTI/rshk2E4t3H23f A2kDk+09vVs29f0+0CW8Bnir7PBwetnes4uOnXTwNulOL7acVgbWl4fJ4PwIVpeHq4zPMn6ViVkm rjI5y+RVpmaZmmT7J+C3wF8fgC3Pj5N855vGH131xyy8W/5HdG7CiZq+78rmUDnAQ+XL8X03seML 752Ya3IIfmavn+oyHIDGnjo47m3vABQTNQZ0+vVJcOHK4+Jx7b4B83ZVHeDflb6uWvttIuLsNPMX 68Y++UN4YTtFmoz7F9JFZYMF99M+v3CGfQcm/7KW47pyZQ1o3jy12ysTvz2vuqnHsHE9kPbgB+jX ic3/dop8/cPn7b8AAAD//wMAUEsDBBQABgAIAAAAIQDZJ7rDbAEAAI0IAAAUAAAAd29yZC93ZWJT ZXR0aW5ncy54bWzslktvgzAMx++T9h1Q7ivQJ0Ollaqqp532+AApmBKJxChJYe2nn4Fua7dOWqU9 Lpwwju38/UOymc6fZe6UoI1AFTG/5zEHVIyJUJuIPT2ubgLmGMtVwnNUELEdGDafXV9Nq7CC9QNY S5HGoSrKhDpimbVF6LomzkBy08MCFJ2lqCW39Ko3LqapiGGJ8VaCsm7f88auhpxbUmAyURh2qFZ9 p1qFOik0xmAMCZF5W09yodiMNCaiNIenU4UioRb9yXAw7E/G4yZAcn0HqaXDkucR85hbh5P3Xmyy M+5HLD7HLtBalB/8dPUi0XU1+56jCCKjQLOv76qNgseEtbFjzJEQ8q3FVkZ+pOyyzPWJosty9XHn l6S6De+m6db8gvykI3/+e/86+aAj/0/kbzvyf0x+NAyCwWjgjxrya0x2S1G+zmj/bc530/905/zk DGq3QLOAsbBCij2sUC80VgY0LVo6P/qJmL0AAAD//wMAUEsDBBQABgAIAAAAIQDPZu14ahAAACaV AAAPAAAAd29yZC9zdHlsZXMueG1s1F3bcts4En3fqv0Hlp52HzK2Jd+SGs+UoySb1CZOZuzsPFMS ZHFDkVqSiuP5+m00QBCkCLAhQImnpmock/QhcLr7oHHlz79+W6fRV1aUSZ5djU5+Oh5FLJvniyS7 vxp9vnvz7HIUlVWcLeI0z9jV6JGVo19/+fvffn54UVaPKSsjAMjKF8XVaFVVmxdHR+V8xdZx+VO+ YRncW+bFOq7g1+L+KF8ukzl7lc+3a5ZVR+Pj4/OjgqVxBS8vV8mmHEm0BwraQ14sNkU+Z2UJpV2n Am8dJ9noFyjeIp+/Yst4m1Yl/7X4VMhf5W/4402eVWX08CIu50lyNZrGaTIrkhFcYXFZXZdJ3Lq4 us7K9mPz8mp0l6yBhxv2EP2er+NsdMShyz8B5GucXo3G4/rKlL+qdS2Ns/v6Gsuefb5tv1pdmiUL eG9cPLu95mBHWJ/6p1avjaqleKpDAlANxN8KwwFFbPk+n39hi9sKblyNwPh48fO7T0WSF0n1eDV6 /lxevGXr5G2yWDDuJ/WD2SpZsD9WLPtcskUD8NsbtLq8MM+3WQU8nF+gYdJy8frbnG241eF9WbyG V9/wP0g5bKm9Bwu0TZrS4IX/1egngthewBWLuRNHWNTAmOMDlHNyAMzTA2CeHQDz/ACYFwfABC0M 7p8YXoH8M8kW7Jvw+BTjWkbqthOmtrgRGOjhnhjo0Z4Y6MGeGOixnhjooZ4Y6JGeGOiBnhjocXtj VPmcpKnYCPYqM0egKKgdgaKXdgSKOtoRKFpoR6Aonx2BonN2BIqq2REoGmZGEE1/9A7EK6u4wu7t m8s8r7K8YlHFvvkhxRngYF7qj8UzEVZ4V8wTQui6zIq8CjOPMXXjGDup2W5LA0+R8rUqnqUsypfR MrnfFtDL8HEEln1lKXRAonixAKxAYAWrtkXmVTDloQVbsgJ6WswLTnPTMIBpkrEo265nnt62ie+D 4LBsgQEdpnY1mrc8KGeNt9WKd5QST4ddx/Mi93KFKo+jENH9Pin9pJMDRC+3acoC4Nz4uyKWxy+f RQi/dBYhTr0sjBB+ySxCCNuIFGzvplZHCsCMLFMAgiRSAJ6E74XgSSIF4EkiBeBJIvnxdJdUKbZg gTqw0zTnY3leYXKb3GcxNNRYrr39W46pRZ/iIr4v4s0q4kOFvGADVTXnuS/zxWN055uZKpQQCTNG 8RQqlmRbP75aSCFipi5VFCBqFFaAuFFYfpHzAbJSniO99e8c3G5nVeA4vI3Trej+eIXiKxhV9gJo nP1NUkBaEaCP2A/p6bE3vNPJTekrXk3p/DKWBscvfBocQb0nTztwnqXj8u4vqW8fN6yAns8XL199 k6dp/sAWYdBuqyIXDeFAe0PtX79eb1ZxmZSEJowK+UpO5EUf4o0XdZ9SmLTzt+PrZzD5l0ZhEoC3 dx/eR3f5hg9J8Pkmrwoi2Mu8qvJ1EDw5ZPaPP9jsn/4Fu4a+Z/YYoIbXAUZbkKpp4tlwCJR84df8 IApkgkkGPfzcb+QHsf7NHmd5XCz8bfYJRkRwjrViAdBu4/VGJPJ7J8xYvztQ0gcYDvEcPUKs/8RF wscEvbiSgXLnDaSNtJXb2X/ZHPsCe7N1k0c8Y/aq28dthcN1mHrjNPfexWlB+WUeLSi/5h2tBnLO fdNzVrMF5VfBFlSICk7TGFawyFm1vU0oilVjhahijRWyjqdeHi/rmKd5sdymQVxiWoMFYawGC0JZ nm7XWRmqlogVqJKIFbKOgdwCy+XXLxcu9q8iWQQhHoFCsI5AIShHoBB8I1Awsv0WWGhW81tloQH5 LbUQQAGaZg0ohB9hiUL4EQKF8CMECuFHCBTCjxAohB8hUAg/mryK2HIJSWeY5kCDC+FTGlwIz+Ij rGy9yYu4eAyQLrxO2X3subBEBOGnIl/yxcZ5JlaqeuZqfNw2VGIroEIYE4YUgrR8HCdUefy86mUM A3Ow1Nh76qVpHLhbDozLmeeBBMwdrJL37dtGt5t4LoecrcXB3iFpGc775H5VRbcrNZRtxT0/tqzA FlBcAwfpOretSBU4PN0YxpFL7XvXHX5gi2S7rusmnNxeu4mldh00dHU72ukwGjYYwyvWz8+IUIRS nQ9DYaZHKNUFEYpQqksiFCqDnfbnFqhXcfFFDcRYYS5snq46kdS4ubD5u0Ijhc6FzeUVFCl6Lmz+ 3hKG6Ho+h8WalBiy8dYohAOgjbpGKhwAbQR2ovzEAdZGZgd27ABLVhEHTJucoCSpVRCDCjzBLgGp qfltC7Omg4BjXFxMAnwHeWNWsogGPKHvJZLmQipcbEXWVgdbkUXWAZOstg6YJNml4znprwOsTU2U eqLhyZJHV2SHctrUpFeaCY2smzQTAG1k7kozAXAfaSbA2sg0STMB1lmaCZg2ae6VJQKmsywRMJ1l iYDpLEsETCdZGsbbS5YIsLZI6pUlAqYtmBQm5vpS6giYtkjqlSVCwu4mSwRAG5m7skQAtDHZ0Q+V MRJgbWR2YFUWQoB1liUCprMsETCdZYmA6SxLBExnWSJgOsnSMN5eskSAtUWSkhA9WyJg2oJJYeqy RMC0RVKvLGGvxToAQBzqqlM6AqCNzF1ZIgDamOzoh5IlAqyNzA6skiUCrLMsETCdZYmA6SxLBExn WSJgOssSAdNJlobx9pIlAqwtkpSE6LJEwLQFk8LUZYmAaYukXlnCadGQskQAtJG5K0sEQBuTHf1Q skSAtZHZgVWyRIB1liUCprMsETCdZYmA6SxLBExnWSJgOsnSMN5eskSAtUWSkhBdlgiYtmBSmLos ETBtkdQrS8OnVjhmSwRAG5m7skQAtDHZ0Q8lSwRYG5kdWCVLBFhnWSJgOssSAdNZlgiYzrJEwHSW JQKmkywN4+0lSwRYWyQpCdFliYBpCyaFqcsSAdMWSXLtDHlT04n7LBIZe0xfXSGL/bt++Ic1vZvQ sevZLwdwHOAjTa29zHPYaEfaZTrB/jkNNZmlSY7bq3Gll36czAQX4O2eJ2NZV/Nxqu/BtPPa4w9w qKJ+PiIe4shPSoS1PhXsa7kabeq94HzSEs5O5GdLyhPW8CzMd3ACojzHkP8xP9gQHsTzHuVlLLyk Bv8N524u6meOj6eXk8sTqfRwXmXnGEl5o/xTO0YSr2mnQWI5Bkquyio3rJ7gqYx6aeU5IjC9j4Wc xXC440d+VuNOXTLYzt53ne+mrK/Xr5mu4kIANnaun4FTJh24gVMueR2/MLa5gQLgX5ZiKRQAzvjO KDDX+BRneOMlbEe6GtUZSS52zbz/mtbvxvFm4FCiSuKLnaNB13AyaMxN3xwN2j35E26qI0LF44JA 8f9piT+/sEJxOZHC2ZwW2lxpzCyueZp5bDSzLEMYM4+fqpnRmb+jmRM0diKN3hh4LFOPVhzjNU8D T4wGli1pGANPnqqB0Y2/o4E1k8qst2VSvOZp0lOjSWVjEMakp0/VpOi4OyadteRUM8OhIuvMaAbZ hQpjhrPgZti/UawTi3aj2GbeqHCHCodzox3kG8PY4fwJ2QEdjB4BKp1okgdx/LinEImTu/tyRNk5 D8P8xRNivtZvjACgb5/U+tLosFKqwtB2+YRoQ3/YcVhdKjxd8bmRU9mHCMPp8yfEaZ0dtsU4ZA9F a0Q9JGQOPbx4Lk9/MHSQ5cFqakUxHqvW7S7Lh7qnr2G7v9t5lN3UpsMvnmsdeg6XzDFc1cdDGMqM O3asPfsIHxnq3Q6VUB2VixWoZqno58I/4PQl6FvCZzGwSyuGIxbfYvFCuD9lafohLjiPFZxZY3w0 ZUveXwegk2PcmNiBmokzaox/X+D2ICMAUKwXRvzKK2HmPsMTPuUmJgP/NzkfjtyJ+/oQDYNb1GMK Q6yby9by5/m2hON7bvmIUHfQpzXC0fVleTM6iRpF6UhUb0xgrfrGUYa8TGxLxD8fHF6yaEhnIAO8 xvitk3ZaeLjxDUd7iKEIkz3Ggewh9XJXlgz+96PNozfFkNU0n6nx6D05GkYMIZgMMwlkGDnq8Zcx jGYKjw6UoylE199kitNAppCjFWZT7BUURD3SeP1+Li768iZezwLxKocfzLx22r5D0mzUle/nzKLj biL9PBDpsj5PgHTIXHC2IlgGI/rfJgIvAhEohwx+EIGaHEhZag3b1gNfYYkVPXQTsZeBiJXy9oOI NQrA96NZdNpNND8PRLMcZzgszeqLhGrakZyQD8tCayZbzQeL+f0ue+Iqdic63RZ9UpsyEYxITSfI zB9thlyOhlDHuP87hy4MTmDzretwQiVW6WlNBzdzg3VZfaaDqalgY5de2/tGjeZAZpPvlZl4xAgs ExAu3TMpH9YK/bHGVwLhcpou5epGiIirwQ4YdJ3lFdQoO/Rs/LAGUqOjxaHJWr4xUr/k6Y3tHCBd Ug2OPOR8h1Rx9nlfAJhHyszSQmtNust+SJ1LRy9TFVdrC7tVVzd+bOWVsKrPIavkQ10ZIEjPBodp 6hfJm7w+4KrLEwz91rf6mNIzk0COoXcS/NZj8bFsNf2xM6iNC2+b24eunUyi4OuAkHHw2YGr0cVY 7sCe84P4vlXbOJVcQ2HAlHtNiIozWbpmFFeH6kjJLREpXDMn1YA78bDzUluSpoy9PPi2IRqZZp/f K88yhroI8jBNRL8EyFXNom5d2uolz1rNPbso+uvCeZMhyCDicD5NhVwdXHJYp85Ra5bd13RQPXOn 2lamfR1Vf9tBEh6jv4qcv+az7mON9xnzUW05T91SphruLnPidqTu94ndE8hqBCdzfoB5TcvZNf+P G8hRAhU10tCq7l1u5P0nT47NbfgUmhaYcqxrW5PIP2cH37DwIFE4ULOro0uidLDmgSfqYZRWAr4o HI446V0NMV3mavdrnnii1An/2yUwIFl8g48YqOmypG39+bH0qE6J+4hotyWtnUwof18ID0tef75y 93EqF3zsZPZwS+1P6mOyXkXCxQJ2Dxl21phTO1o/V+Yiu+OeOKpdZyDwE1WclwT/AYyJpUKtlEIp /TRfr2FUtYmkrhdp388p1O63Phb2aQs7s5ztVS+Ts/PLc7kWgNzJb2LtpGf6Ulzb10UkV3gctYUm 3vUSrmDJafX1QRouJXV1Ja2hpO4fthq+ehdVoHmzbmW6RMn7eKi3bz6qvUsQbo6xDmnG3tQeTufp TpAG4FepukRpgVfKR/rCbocDXX92bva4nXz/ITxPNH8zHKkfZqklUJZFe7JSerm73MlHIvmM2c80 ghoCzCQd0MvcuOpvw+SB+b0C1TpMv8+R9KE3nQENtKGIHGh0SZdZwl28yte4W1OOXDYXsHcobmMF GmHz0Xqq23V56PqcTrDZ4cytpIHzA7pcdw1pw/R3or7lxZaIX5d5CmOv6vHjnRSt+4RgzdL+mh24 7bHH55PXp9iXVvuMe4ZcQdxketZNVMxbjjsuLHb7dDJaXKI6rJyKGDyUmy905jva8eOsvVqgfbbV RQkU4B460D4PAN9qbIMvLo4npzjPqMbTuq4Kn5oBn4hLfVc3fpjjarROsrx4e52VCb9ZT39oz8/L in/CQz75MlkkwlsaOYGDIaR1tAECvDZsC6qctMnsikljIV8pUe9xFJJ2GPylTAJGwv5N+cv/BQAA AP//AwBQSwMEFAAGAAgAAAAhAF6h4YKOAQAAKQMAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEo oAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJySy07DMBBF90j8Q+R9artAQVEbJECsQEKi qIidsafFNLEteyDk73GcJrSCFcvxvXPm5fnlV11ln+CDtmZB+ISRDIy0SpvNgjwtb/MLkgUURonK GliQFgK5LI+P5tIV0np48NaBRw0hiyQTCukW5A3RFZQG+Qa1CJPoMFFcW18LjKHfUCfkVmyAThmb 0RpQKIGCdsDcjUSyQyo5It2HrxJASQoV1GAwUD7h9MeL4OvwZ0JS9py1xtbFmXbt7rOV7MXR/RX0 aGyaZtKcpDZi/5w+3989plFzbbpdSSDlXMkCNVZQ3kCQXjuMC87sOltZv53TUe184eP1HSSW6XkM oiA9CLS+FFXVmqQOL936t9A21qsQ8w6imKh+avbUg4forkTA+3jltQZ11Q4FfgtdHQ+fuvse5TQV GsNO6zgPXhsEVU4ZZzk7yzlfMlbw84Kxl5Sxb4rzpjP0s4HK4mKL/gyDsjq5vlnekh1vlrPpks8K dtrzBlfaRKw6AuvdOP8mDoB+n4efu/wGAAD//wMAUEsDBBQABgAIAAAAIQCvBqpuPwMAAMwPAAAS AAAAd29yZC9udW1iZXJpbmcueG1stJdbb5swFMffJ+07REh7TCGEXBqVVlm7SJ22bpqyD+CAU6z5 gmyTNN9+xwZT2lQoW52XEPgfn8vPFw5XN0+MDnZYKiJ4GowuomCAeSZywh/T4Pd6NZwHA6URzxEV HKfBAavg5vrjh6v9gldsgyUYDsAHV4sdyIXW5SIMVVZghtSFKDEHcSskQxpu5WPIkPxTlcNMsBJp siGU6EMYR9E0aNyINKgkXzQuhoxkUiix1WbIQmy3JMPNxY2Qp8StR96JrGKYaxsxlJhCDoKrgpTK eWP/6w1KLJyTXV8RO0ad3b48JVou0R44M1qnvRcyL6XIsFLw9K4WW4+jqC92A9C4aEecksLLmC4T hghv3Zjl8Wr+28m7gMkL69ihcfVcCLC4hsWENkpLlOmHig1e3N3naRBZE65IDtoO0TSYfV7Gkyie BaEZzCqqyTe8w3R9KLGzKQ4bSfLvRqNGq201K6mzuI1vp5dfVstaoTsjELiYiPBXlzRLg8l8uhwv 7+Z1DhVbMe3GbypKsW5Hr/FTKw3bp18zZ07xtjEuf0qTN+GmIPMYKoptzALxR7v3xtPIuAj3i8ZY 1mPkSnCtYBhSGSFpcIsogTpNvhgpvVQEpcGaMKwGD3g/+CUYginaL4ol8HthXhAOcXO8RYCoiWWD QEyAYBLsIhk9I4mS6DKKorFFAqeDbMse1WXD0dDBlOOMMNTwB5ddTp/ii1NIaVgfJiG4Qi12CUAM k1EpFJxbSeJoOcsuWysbBifDzcDpa4j1bPQQio8ITXwQGvsgFI/a9fQWISufn9D4iNDIB6HEC6H5 vG8NxUY+P6HkiJCXXTbxQQiOpD5CVj4/ockRIS+7bOqDUDKGU7w+J97aZVY+PyFopdzLqzmpveyy mQ9CE8ioh5CVz09odkTIyy6beyE06z2pJ0Y+PyFo+1+tIS+77NIHoWnSe1Jb+RyEoC/qtKmmHYEe BALBr+lS603Wsbg33Z3tVeySt+3UD/jWgq7UNKmu07QtLLRFR1Jn13Y069D2WXWf5qSmX3O3bYD4 +Q3b0f7VS2d/vMNL4iWXzkp8Ry5TL7nMvHipPy5sJ31SRTDzsOjs1wFc66/w678AAAD//wMAUEsD BBQABgAIAAAAIQB2tYUa9QEAAC0IAAASAAAAd29yZC9mb250VGFibGUueG1sxJXdbptAEIXvK/Ud 0N4nLNixHSs4ctL6shdV+gBjWMxK+4N2sEnevrMsdtU6jiBSE5CQmGGH4dtzhrv7Z62ig3AorclY cs1ZJExuC2l2Gfv1tLlasAgbMAUoa0TGXgSy+9XXL3ftsrSmwYjWG1y6jFVNUy/jGPNKaMBrWwtD udI6DQ3dul1sy1Lm4pvN91qYJk45n8VOKGjo3VjJGllfrR1SrbWuqJ3NBSI1q1Wop0Eatuq7i9ql AU1dP4KSWye7RA3GokgodwCVMZ7yDb+hqz+nfOKvLPYV8gociub0IA/hErRUL8cothIxJGrZ5NUx fgAnYatESKHcUWKPW56xNacj/b5hIZJkbOoDfP7QR1Jqqj/6yOTvSN7VCY/cdnUoQnVOq6j9OOzP GYknqQVGP0Qb/bQaAqpzIimfEYkb4uHJTEYRcV3djuBAIiQEnq4X8z9ETl8SGI0hkmxGEnkETdKA C9rwBAIJT2ScNsaTeF0bnE8/RhtQ0d5dAPFAkvD28KKYjgQx3iSz5F9JLHpNnJmEBlRnrUsmSfh4 SdA8sgrwDRS3hOA980LbQjjzysAo5bMohk+Lj1HEmoyh3qDghXA8/+/U/OQZYfdOCufn5gUac7JG 0ISfmGSRsJWD/iFjNXHO4t3m4APM0f9KcPUbAAD//wMAUEsDBBQABgAIAAAAIQDCFHYE+QEAAPgD AAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AJxTwW7bMAy9D9g/GL43crIuSwNGxZBg6GFbA8Rtz5pMJ0JtSZDYoNnXj7KbxFl3mk/kI009vUfB 7WvbZHsM0Ti7yMejIs/QalcZu13kD+W3q1meRVK2Uo2zuMgPGPNb+fEDrIPzGMhgzHiEjYt8R+Tn QkS9w1bFEZctV2oXWkWchq1wdW00rpx+adGSmBTFVOAroa2wuvKngXk/cb6n/x1aOZ34xcfy4Jmw hBJb3yhC+TPRaUaVoxbECYXSkWpK06IcM3xKYK22GOUnEH0ATy5UUd7MvoDoQ1juVFCaWEH5eTaZ ghgA8NX7xmhFLK78YXRw0dWU3XcyZGkAiGELsDQb1C/B0EEWIIYpfDeWqVzPQPQRcwtqG5TfRTnu GJ5S2GjV4JIVkLVqIoI4A3CHKrm7VoYpw57me9TkQhbNb/Z3kme/VMSk2yLfq2CUJdYvtfVJFzc+ UpCloYZnc63Pu3DYNozNdZKWezm4bExgz4ELl+y6E+J9zVelf5AdD8l2HHqqPZ0VRh2MT+Jnrk5y P78j212dj/3roKVrvbIHuTRRO7b0LU0ePMcHX7pV2qU3bS/BwUI8GdptvNJs23RWsJ/n1RiUYMMb hBV7fRx4BuCOfQhNOpX/tVusjj3vC2nZHvuHLMeTUcFft11HjHf49MLkHwAAAP//AwBQSwECLQAU AAYACAAAACEAMMkoDHIBAAClBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAAAKsDAABfcmVscy8ucmVs c1BLAQItABQABgAIAAAAIQCzvosdCQEAALYDAAAcAAAAAAAAAAAAAAAAAM8GAAB3b3JkL19yZWxz L2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhACtqkkmTGAAAdpMAABEAAAAAAAAAAAAA AAAAGgkAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAAA AAAAAAAAAAAA3CEAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAwPZWdjgUA ADYSAAARAAAAAAAAAAAAAAAAAKUoAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQDZ J7rDbAEAAI0IAAAUAAAAAAAAAAAAAAAAAGIuAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQA BgAIAAAAIQDPZu14ahAAACaVAAAPAAAAAAAAAAAAAAAAAAAwAAB3b3JkL3N0eWxlcy54bWxQSwEC LQAUAAYACAAAACEAXqHhgo4BAAApAwAAEQAAAAAAAAAAAAAAAACXQAAAZG9jUHJvcHMvY29yZS54 bWxQSwECLQAUAAYACAAAACEArwaqbj8DAADMDwAAEgAAAAAAAAAAAAAAAABcQwAAd29yZC9udW1i ZXJpbmcueG1sUEsBAi0AFAAGAAgAAAAhAHa1hRr1AQAALQgAABIAAAAAAAAAAAAAAAAAy0YAAHdv cmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQDCFHYE+QEAAPgDAAAQAAAAAAAAAAAAAAAA APBIAABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAAMAAwAAQMAAB9MAAAAAA== ------_=_NextPart_001_01CB026E.58616D6D-- From allyn@cisco.com Wed Jun 2 09:15:59 2010 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 A649328C0F6 for ; Wed, 2 Jun 2010 09:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=-1.525, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTljgsT-l-GD for ; Wed, 2 Jun 2010 09:15:55 -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 B19BB3A69FC for ; Wed, 2 Jun 2010 09:15:55 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQLACYgBkyrR7Hu/2dsb2JhbACBP4FakDiKSXGnEIkKCJEcgleBTXIEgn5K X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="scan'208,217";a="225045941" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 02 Jun 2010 16:15:42 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o52GFgRT001876; Wed, 2 Jun 2010 16:15:42 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 09:15:42 -0700 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_01CB026E.D90AF443" Date: Wed, 2 Jun 2010 09:15:41 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01761012@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Multi-streams for telepresence description of work Thread-Index: Acr3FUA3cn+LxT6FQlWqmQmFo+y7tgLWTUWA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 02 Jun 2010 16:15:42.0414 (UTC) FILETIME=[D93776E0:01CB026E] Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work 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, 02 Jun 2010 16:15:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB026E.D90AF443 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Gao, =20 I had a chance to talk with Mary about your idea to split up the work, = and she confirmed that it is good practice in general to do so, but we = thought it is as yet too early to split up the multi-stream work. As we = progress with use cases, problem statement and requirements, we will be = able to see better if the topic should be split up. =20 Best regards, Allyn =20 From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 Sent: Tuesday, May 18, 2010 10:33 PM To: Allyn Romanow (allyn) Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of = work =20 Hi,=20 I have two level of comments,=20 1. Feeling for the topic=20 Technically, I am quit glad to see such discussion about telepresence, = which is trailblazer for VR(Virtual Reality) production.=20 2. About the charter WG=20 One revolutionary application, such telepresence, would cover basic = protocol level, application control level, and interworking issue.=20 If the work is just focused on pure interworking issue, then the topics = can be divided into smaller one, which might be in other basic = protocols' WG's scope. But if the application itself is new, and has = some new characteristic, more work should be proposed.=20 If the work is also focused on telepresence application, which is a = conferencing system, the xcon WG might be proper one for application = level definition.=20 If the charter also want to talk the esential aspect of telepresence(or = more abstractly, about VR), such as how to using SDP, or relative = protocol to describe the streams and it's collaboration, it would be = quite new topic. One new WG might be better.=20 I find the charter seems covers all the three thing. So, I suggest you = classify such different level requirement. Then, we may find which part = is proper for which WG, and which part should be covered by new WG.=20 Thanks,=20 Gao=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 "Allyn Romanow (allyn)" =20 =B7=A2=BC=FE=C8=CB: dispatch-bounces@ietf.org=20 2010-05-19 02:30=20 =CA=D5=BC=FE=C8=CB "IETF DISPATCH list" =20 =B3=AD=CB=CD =09 =D6=F7=CC=E2 [dispatch] Multi-streams for telepresence description of work =20 =09 Hi Folks,=20 =20 Many of you are aware of telepresence systems (video conferencing on = steroids..:), fewer probably are aware of the fact that the current = systems are not interoperable with each other. After talking with Mary = and Cullen, we have a rough draft of a charter to work on this problem = in DISPATCH, for discussion on the mailing list.=20 =20 We don=A1=AFt yet know whether a working group would need to be spun out = or not =A8C that will be clarified as we go.=20 =20 We think there is enough background info in the work description to = start a discussion, and plan to send out use cases for discussion = shortly.=20 =20 Who is the we? Several makers and providers of telepresence systems have = gotten together to define the main problem in interoperability =A8C the = handling of multi-streams.=20 =20 Thanks for your thoughts-=20 Allyn=20 =20 =20 Multi-streams for Telepresence Description of Work=20 =20 =20 =20 Background=20 One branch of video conferencing has evolved that is focused on = immersive =A1=B0being there=A1=B1 experience. Referred to in various = ways such as virtual conferencing, telepresence or media spaces, early = systems were mainly research projects or business systems with limited = deployments. In recent years telepresence systems have seen = considerable market success. Following the model of early systems, the = first wave of commercial systems have been typically located in = specially designed single-purpose rooms with multiple relatively large = displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones. These systems have several = important characteristics that are different from more traditional video = conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order = to improve participant nonverbal communication. These systems preserve = essential group meeting characteristics such as eye contact, group = gestures, seating order and spatial audio by carefully orchestrating the = miking and camera angles at each of the sites . This is distinct from = the more traditional approach where the geometric relationship between = media streams is not used to preserve inter-stream communication aspects = such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve = immersion. With telepresence systems, cinematographic aspects of the = local environment reproduction are carefully planned including color, = table shape, seating and lighting so that when combined with large high = quality displays, a strong sense of a "trompe l'oeil" or "being there" = immersive experience is created. Typical video conference systems do = not include these considerations.=20 =20 As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal = communication and immersive values of telepresence via smaller, less = expensive and more flexible video conferencing systems for a variety of = venues, such as individual offices, homes and kiosks. These are also = telepresence systems, since the audio and video quality is high enough = to allow clear image reproduction for nonverbal communication, they are = able to send and receive multiple media streams, and large coordinated = multi image displays are available for immersive installations. As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available.=20 =20 Problem=20 Although telepresence systems are based on open standards such as RTP, = SIP, H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call. A major factor in the inability of Telepresence systems = to work with each other is that there is no standard description of the = multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio = streams sent from remote participants must be understood by receivers so = that they can be presented in a coherent and life-like manner. This = includes the ability to present the remote participants at their true = size for their apparent distance, while maintaining correct eye contact, = gesticular cues, and simultaneously providing a spatial audio sound = stage consistent with the video presentation. The receiving device that = decides how to display the incoming information needs to understand a = number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is = related to each of the displays, etc.=20 =20 Charter=20 The Telepresence Multi-Streams work item in DISPATCH is chartered to = define and specify the content of media multi-stream messages and the = way these will be transported.=20 This work is aimed at providing a standard for the exchange of media = semantics information that will foster interoperable end stations and = conference bridges. This work item will specify the variables that = describe the semantics of the media streams and the recommended behavior = to achieve interoperability. =20 =20 This requires considering current widely deployed use cases, such as = single and multiple screens, multi-point, Scalable Video Coding (SVC), = as well as cases that are expected to be implemented using the protocol = framework produced by this work item. The methodology for describing = the variables must allow extensibility of the variables, since = telepresence is still a young technology and may have use cases that are = not currently considered.=20 =20 The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media = streams, including a specification of variables required to support the = use cases. This work item will consider the reuse of existing IETF = protocols and produce an architecture/protocol framework document = describing the protocols required to be implemented to support this = functionality. The document will identify any enhancements required to = existing protocols as well as describing new protocol(s) for = interoperable multi-streams negotiation that may be required.=20 =20 Scope=20 The scope includes both systems that provide a fully immersive = experience, and systems that interwork with them and therefore need to = understand the same multiple stream semantics.=20 =20 The focus of this work is on audio and video multiple streams, however = other media types may be considered. Definition of new application = protocols is not within the scope of this work=20 =20 [Is there anything else we need to explicitly say is out of scope?]=20 =20 The group will produce=20 - Requirements and use cases=20 =20 - Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing = protocol enhancements and new protocol functionality required=20 =20 - Specification of a new protocol to support telepresence multi-streams = [if required]=20 =20 Goals and Milestones=20 Nov 2010=20 Use Cases and Requirements to IESG as Informational RFC=20 March 2011=20 Architecture to IESG as Informational RFC=20 March 2011=20 Revise Charter [IF new protocol is not required]=20 Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 =20 =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01CB026E.D90AF443 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Gao,

 

I had a chance to talk with Mary about your idea to split = up the work, and she confirmed that it is good practice in general to do so, = but we thought it is as yet too early to split up the multi-stream work.  = As we progress with use cases, problem statement and requirements, we will be = able to see better if the topic should be split up.

 

Best regards,

Allyn

 

From:= gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Tuesday, May 18, 2010 10:33 PM
To: Allyn Romanow (allyn)
Cc: IETF DISPATCH list
Subject: Re: [dispatch] Multi-streams for telepresence = description of work

 


Hi, =

I have = two level of comments,

1. = Feeling for the topic
Technically, = I am quit glad to see such discussion about telepresence, which is = trailblazer for VR(Virtual Reality) production.

2. = About the charter WG
One revolutionary application, such telepresence, would cover basic protocol = level, application control level, and interworking issue.

If the = work is just focused on pure interworking issue, then the topics can be divided = into smaller one, which might be in other basic protocols' WG's scope. But if = the application itself is new, and has some new characteristic, more work = should be proposed.

If the = work is also focused on telepresence application, which is a conferencing = system, the xcon WG might be proper one for application level definition. =

If the = charter also want to talk the esential aspect of telepresence(or more = abstractly, about VR), such as how to using SDP, or relative protocol to describe the = streams and it's collaboration, it would be quite new topic. One new WG might be = better.


I find = the charter seems covers all the three thing. So, I suggest you classify = such different level requirement. Then, we may find which part is proper for = which WG, and which part should be covered by new WG.

Thanks,

Gao =

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

"Allyn Romanow (allyn)" <allyn@cisco.com> =
=B7=A2=BC=FE=C8=CB: =  dispatch-bounces@ietf.org

2010-05-19 02:30

=CA=D5=BC=FE=C8=CB

"IETF DISPATCH list" <dispatch@ietf.org>

=B3=AD=CB=CD

=D6=F7=CC=E2

[dispatch] Multi-streams for telepresence description of = work

 




Hi = Folks,
 =
Many = of you are aware of telepresence systems (video conferencing on steroids..:), fewer probably are aware of the fact that the current systems are not = interoperable with each other. After talking with Mary and Cullen, we have a rough = draft of a charter to work on this problem in DISPATCH,  for discussion on the mailing list.
 =
We = don=A1=AFt yet know whether a working group would need to be spun out or not =A8C that = will be clarified as we go.
 =
We = think there is enough background info in the work description to start a discussion, = and plan to send out use cases for discussion shortly.
 =
Who is = the we? Several makers and providers of telepresence systems have gotten = together to define the main problem in interoperability =A8C the handling of = multi-streams.
 =
Thanks = for your thoughts-
Allyn =
 =
 =


Multi-streams= for Telepresence Description of Work
 =
 =


 =
Background
One = branch of video conferencing has evolved that is focused on immersive =A1=B0being = there=A1=B1 experience.  Referred to in various ways such as virtual = conferencing, telepresence or media spaces, early systems were mainly research = projects or business systems with limited deployments.  In recent years = telepresence systems have seen considerable market success.  Following the model = of early systems, the first wave of commercial systems have been typically = located in specially designed single-purpose rooms with multiple relatively = large displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones.  These systems have several important = characteristics that are different from more traditional video conferencing systems. =  
 =
The = first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, seating = order and spatial audio by carefully orchestrating the miking and camera angles at = each of the sites . This is distinct from the more traditional approach where = the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group = dynamics.  
 =
A = second difference is manipulation of the environment to improve immersion. =  With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating = and lighting so that when combined with large high quality displays, a = strong sense of a "trompe l'oeil" or "being there" immersive = experience is created.  Typical video conference systems do not include these considerations.
 =
As = telepresence video systems have become successful in the market, manufacturers have = started exploring delivery of the nonverbal communication and immersive values = of telepresence via smaller, less expensive and more flexible video = conferencing systems for a variety of venues, such as individual offices, homes and = kiosks. These are also  telepresence systems, since the audio and video = quality is high enough to allow clear image reproduction for nonverbal = communication, they are able to send and receive multiple media streams, and large = coordinated multi image displays are available for immersive installations.   = As the industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive installations = become broadly available.
 =
Problem
Although telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one = vendor to another. It would be like having to make sure all parties are on the = same equipment (and network) when making a telephone call.  A major = factor in the inability of Telepresence systems to work with each other is that = there is no standard description of the multiple streams that comprise the media = flows.
 =
For = example, in a multiple screen conference, the video and audio streams sent from = remote participants must be understood by receivers so that they can be = presented in a coherent and life-like manner. This includes the ability to present the = remote participants at their true size for their apparent distance, while = maintaining correct eye contact, gesticular cues, and simultaneously providing a = spatial audio sound stage consistent with the video presentation.  The = receiving device that decides how to display the incoming information needs to = understand a number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is related to = each of the displays, etc.
 =
Charter
The Telepresence Multi-Streams work item in DISPATCH is chartered to define = and specify the content of media multi-stream messages and the way these = will be transported.
This = work is aimed at providing a standard for the exchange of media semantics = information that will foster interoperable end stations and conference bridges. This = work item will specify the variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability. =  
 =
This = requires considering current widely deployed use cases, such as single and = multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that = are expected to be implemented using the protocol framework produced by this = work item.  The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently considered.
 =
The = work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, = including a specification of variables required to support the use cases. This = work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality.  The document will = identify any enhancements required to existing protocols as well as describing = new protocol(s) for interoperable multi-streams negotiation that may be = required.
 =
Scope<= /b>
The = scope includes both systems that provide a fully immersive experience, and = systems that interwork with them and therefore need to understand the same = multiple stream semantics.
 =
The = focus of this work is on audio and video multiple streams, however other media = types may be considered.  Definition of new application protocols is not = within the scope of this work
 =
[Is = there anything else we need to explicitly say is out of scope?]
 
The = group will produce
- = Requirements and use cases
 =
- = Architectural Framework describing the protocols required to be implemented to support = this functionality and identifying existing protocol enhancements and new = protocol functionality required
 =
- = Specification of a new protocol to support telepresence multi-streams [if = required]
 =
Goals and Milestones

Nov 2010

Use Cases and Requirements to IESG as Informational RFC =

March 2011

Architecture to IESG as Informational RFC

March 2011

Revise Charter [IF new protocol is not required]

Nov 2011

Submit protocol draft to IESG as Proposed Standard RFC


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

 
----------------------------------------=
----------------
ZTE Information Security&=
nbsp;Notice: The information contained in this&n=
bsp;mail is solely property of the sender's=
 organization. This mail communication is c=
onfidential. Recipients named above are obligate=
d to maintain secrecy and are not perm=
itted to disclose the contents of this =
;communication to others.
This email&=
nbsp;and any files transmitted with it are&=
nbsp;confidential and intended solely for the&nb=
sp;use of the individual or entity to =
whom they are addressed. If you have r=
eceived this email in error please notify&n=
bsp;the originator of the message. Any view=
s expressed in this message are those =
of the individual sender.
This m=
essage has been scanned for viruses and&nbs=
p;Spam by ZTE Anti-Spam system.
------_=_NextPart_001_01CB026E.D90AF443-- From peter.musgrave@magorcorp.com Wed Jun 2 09:40:19 2010 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 BA8D53A6872 for ; Wed, 2 Jun 2010 09:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, 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 M6ITzr8MH0Px for ; Wed, 2 Jun 2010 09:40:17 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 7FE023A6828 for ; Wed, 2 Jun 2010 09:40:16 -0700 (PDT) Received: by gwj19 with SMTP id 19so4900511gwj.31 for ; Wed, 02 Jun 2010 09:39:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.210.16 with SMTP id i16mr8802279ybg.70.1275496798349; Wed, 02 Jun 2010 09:39:58 -0700 (PDT) Received: by 10.150.199.12 with HTTP; Wed, 2 Jun 2010 09:39:58 -0700 (PDT) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0176100E@xmb-sjc-221.amer.cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0176100E@xmb-sjc-221.amer.cisco.com> Date: Wed, 2 Jun 2010 12:39:58 -0400 Message-ID: From: Peter Musgrave To: "Allyn Romanow (allyn)" Content-Type: multipart/alternative; boundary=000e0cd379aa93e98304880ebd77 Cc: dispatch@ietf.org Subject: Re: [dispatch] Updated charter/work description for telepresence multi-streams 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, 02 Jun 2010 16:40:19 -0000 --000e0cd379aa93e98304880ebd77 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I read this through. I think it describes the work well enough at this point. Is it worth narrowing the scope of how media will be transmitted? I assume it will be RTP but this not explicitly stated. Regards, Peter Musgrave On Wed, Jun 2, 2010 at 12:11 PM, Allyn Romanow (allyn) wro= te: > Folks, > > Here is a version of the work description that addresses the comments mad= e > on the first draft. > > The changes include: > > 1. Charter section, qualification that we are working on SIP-based > systems > > 2. Charter section, minor word smithing > > 3. Charter section, reference to RAI WG with relevant work > > 4. Scope section, clarification of interoperability requirements > > 5. Scope section, replacement of second paragraph regarding > treatment of non-video non-audio media types > > 6. Goals and Milestones =96 addition of a Problem Statement draft > > > > > > Comments welcome > > > > Allyn > > > > *Multi-streams for Telepresence Description of Work* > > * * > > * * > > * * > > *Background* > > One branch of video conferencing has evolved that is focused on immersive > =93being there=94 experience. Referred to in various ways such as virtua= l > conferencing, telepresence or media spaces, early systems were mainly > research projects or business systems with limited deployments. In recen= t > years telepresence systems have seen considerable market success. Follow= ing > the model of early systems, the first wave of commercial systems have bee= n > typically located in specially designed single-purpose rooms with multipl= e > relatively large displays permitting life size image reproduction, multip= le > cameras, encoders, decoders and microphones. These systems have several > important characteristics that are different from more traditional video > conferencing systems. > > > > The first difference concerns controlling the visual viewpoint in order t= o > improve participant nonverbal communication. These systems preserve > essential group meeting characteristics such as eye contact, group gestur= es, > seating order and spatial audio by carefully orchestrating the miking and > camera angles at each of the sites . This is distinct from the more > traditional approach where the geometric relationship between media strea= ms > is not used to preserve inter-stream communication aspects such as eye > contact and group dynamics. > > > > A second difference is manipulation of the environment to improve > immersion. With telepresence systems, cinematographic aspects of the loc= al > environment reproduction are carefully planned including color, table sha= pe, > seating and lighting so that when combined with large high quality displa= ys, > a strong sense of a "trompe l'oeil" or "being there" immersive experience= is > created. Typical video conference systems do not include these > considerations. > > > > As telepresence video systems have become successful in the market, > manufacturers have started exploring delivery of the nonverbal communicat= ion > and immersive values of telepresence via smaller, less expensive and more > flexible video conferencing systems for a variety of venues, such as > individual offices, homes and kiosks. These are also telepresence system= s, > since the audio and video quality is high enough to allow clear image > reproduction for nonverbal communication, they are able to send and recei= ve > multiple media streams, and large coordinated multi image displays are > available for immersive installations. As the industry develops, the li= ne > between telepresence and video conferencing may become blurred as nonverb= al > communication and immersive installations become broadly available. > > > > *Problem* > > Although telepresence systems are based on open standards such as RTP, SI= P, > H.264, H.323 suite, they cannot easily interoperate with each other witho= ut > operator assistance and expensive additional equipment that translates fr= om > one vendor to another. It would be like having to make sure all parties a= re > on the same equipment (and network) when making a telephone call. A majo= r > factor in the inability of Telepresence systems to work with each other i= s > that there is no standard description of the multiple streams that compri= se > the media flows. > > > > For example, in a multiple screen conference, the video and audio streams > sent from remote participants must be understood by receivers so that the= y > can be presented in a coherent and life-like manner. This includes the > ability to present the remote participants at their true size for their > apparent distance, while maintaining correct eye contact, gesticular cues= , > and simultaneously providing a spatial audio sound stage consistent with = the > video presentation. The receiving device that decides how to display the > incoming information needs to understand a number of variables such as th= e > spatial position of the speaker, the field of view of the cameras, the > camera zoom, which media stream is related to each of the displays, etc. > > > > *Charter* > > The Telepresence Multi-Streams work item in DISPATCH is chartered to defi= ne > and specify for SIP-based systems the content of media multi-stream messa= ges > and the way these will be transported. > > > > This work will provide a standard for the exchange of media semantic > information that will foster interoperable end stations and conference > bridges. It will specify variables that describe the semantics of the > media streams and the recommended behavior to achieve interoperability. > > > > This requires considering current widely deployed use cases, such as sing= le > and multiple screens, multi-point, Scalable Video Coding (SVC), as well a= s > cases that are expected to be implemented using the protocol framework > produced by this work item. The methodology for describing the variables > must allow extensibility of the variables, since telepresence is still a > young technology and may have use cases that are not currently considered= . > > > > The work item will identify use cases, define requirements, and define a > method for describing and transporting information about multiple media > streams, including a specification of variables required to support the u= se > cases. This work item will consider the reuse of existing IETF protocols = and > produce an architecture/protocol framework document describing the protoc= ols > required to be implemented to support this functionality. The document w= ill > identify any enhancements required to existing protocols as well as > describing new protocol(s) for interoperable multi-streams negotiation th= at > may be required. > > > > Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and > FECframe. > > > > *Scope* > > The scope includes both systems that provide a fully immersive experience= , > and systems that interwork with them and therefore need to understand the > same multiple stream semantics. > > > > > > The focus of this work is on audio and video multiple streams. Other med= ia > types may be considered, however development of methodologies for them is > not within the scope of this work. > > > > Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. However, backwards compatibility w= ith > existing non-standards compliant telepresence systems is not required. > > > > * * > > > > *The group will produce* > > - Requirements and use cases > > > > - Architectural Framework describing the protocols required to be > implemented to support this functionality and identifying existing protoc= ol > enhancements and new protocol functionality required > > > > - Specification of a new protocol to support telepresence multi-streams [= if > required] > > > > *Goals and Milestones* > > Nov 2010 > > > > Use Cases and Requirements to IESG as Informational RFC > > Nov 2010 > > March 2011 > > Problem Statement to IESG as Informational RFC > > Architecture to IESG as Informational RFC > > March 2011 > > Revise Charter [IF new protocol is not required] > > Nov 2011 > > Submit protocol draft to IESG as Proposed Standard RFC > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --000e0cd379aa93e98304880ebd77 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,=A0

I read this through. I think it describes the wor= k well enough at this point.=A0

Is it worth narrow= ing the scope of how media will be transmitted? I assume it will be RTP but= this not explicitly stated.

Regards,

Peter Musgrave
On Wed, Jun 2, 2010 at 12:11 PM, Allyn Romanow = (allyn) <allyn@cisc= o.com> wrote:

Folks,

Here is a version of the work description that addre= sses the comments made on the first draft.

The changes include:

1.=A0=A0=A0= =A0=A0=A0 Charter section, qualification that we are working on SIP-based systems

2.=A0=A0=A0= =A0=A0=A0 Charter section, minor word smithing

3.=A0=A0=A0= =A0=A0=A0 Charter section, reference to RAI WG with relevant work

4.=A0=A0=A0= =A0=A0=A0 Scope section, clarification of interoperability requirements

5.=A0=A0=A0= =A0=A0=A0 Scope section, replacement of second paragraph regarding treatment of non-video non-audio media types

6.=A0=A0=A0= =A0=A0=A0 Goals and Milestones =96 addition of a Problem Statement draft

=A0

=A0

Comments welcome

=A0

Allyn

=A0

Multi-streams for Telepresence Description of Work

=A0

=A0

=A0

Background

One branch of video conferencing has evolved that is focused on immersive =93being there=94 experience.=A0 Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly resea= rch projects or business systems with limited deployments.=A0 In recent years telepresence systems have seen considerable market success.=A0 Following th= e model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones.=A0 These systems have several important characteristics that are different from more traditional video conferencing systems.=A0

=A0

The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order = and spatial audio by carefully orchestrating the miking and camera angles at ea= ch of the sites . This is distinct from the more traditional approach where th= e geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics.=A0

=A0

A second difference is manipulation of the environment to improve immersion.=A0 With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating an= d lighting so that when combined with large high quality displays, a strong s= ense of a "trompe l'oeil" or "being there" immersive exp= erience is created.=A0 Typical video conference systems do not include these considerations.

=A0

As telepresence video systems have become successful in the market, manufactur= ers have started exploring delivery of the nonverbal communication and immersiv= e values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, h= omes and kiosks. These are also=A0 telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverba= l communication, they are able to send and receive multiple media streams, an= d large coordinated multi image displays are available for immersive installations.=A0=A0 As the industry develops, the line between telepresenc= e and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available.

=A0

Problem

Although telepresence systems are based on open standards such as RTP, SIP, H.264, H= .323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vend= or to another. It would be like having to make sure all parties are on the sam= e equipment (and network) when making a telephone call. =A0A major factor in the inability of Telepresence systems to work with each other is that there= is no standard description of the multiple streams that comprise the media flo= ws.

=A0

For example, in a multiple screen conference, the video and audio streams sent from remo= te participants must be understood by receivers so that they can be presented = in a coherent and life-like manner. This includes the ability to present the rem= ote participants at their true size for their apparent distance, while maintain= ing correct eye contact, gesticular cues, and simultaneously providing a spatia= l audio sound stage consistent with the video presentation.=A0 The receiving device that decides how to display the incoming information needs to unders= tand a number of variables such as the spatial position of the speaker, the fiel= d of view of the cameras, the camera zoom, which media stream is related to each= of the displays, etc.

=A0

Charter

The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify for SIP-based systems the content of media multi-stream messages an= d the way these will be transported.

=A0

This work will provide a standard for the exchange of media semantic information that will foster interoperable end stations and conference bridges. = It will specify=A0 variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability.=A0

=A0

This requires considering current widely deployed use cases, such as single and multiple screens, multi-point, Scalable Video Coding (SVC), as well as case= s that are expected to be implemented using the protocol framework produced b= y this work item.=A0 The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technol= ogy and may have use cases that are not currently considered.

=A0

The work item will identify use cases, define requirements, and define a method= for describing and transporting information about multiple media streams, inclu= ding a specification of variables required to support the use cases. This work i= tem will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required = to be implemented to support this functionality.=A0 The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be require= d.

=A0

Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and FECframe.

=A0

Scope<= /b>

The scope includes both systems that provide a fully immersive experience, and system= s that interwork with them and therefore need to understand the same multiple stream semantics.

=A0

=A0

The focus of this work is on audio and video multiple streams.=A0 Other media types may be considered, however development of methodologies for them is n= ot within the scope of this work.

=A0

Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. =A0However, backwards compatibility with existing non-standards compliant telepresence systems is not required.

=A0

=A0

=A0

The group will produce

- Requirements and use cases

=A0

- Architectural Framework describing the protocols required to be implemented= to support this functionality and identifying existing protocol enhancements a= nd new protocol functionality required

=A0

- Specification of a new protocol to support telepresence multi-streams [if required]

=A0

Goals and Milestones

Nov 2010

=A0

Use Cases and Requirements to IESG as Informational RFC

Nov 2010

March 2011

Problem Statement to IESG as Informational RFC

Architecture to IESG as Informational RFC

March 2011

 Revise Charter [IF new protocol is not required]

Nov 2011

Submit protocol draft to IESG as Proposed Standard RFC

=A0

=A0

=A0


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


--000e0cd379aa93e98304880ebd77-- From allyn@cisco.com Wed Jun 2 09:45:19 2010 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 008FB28C136 for ; Wed, 2 Jun 2010 09:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.236 X-Spam-Level: X-Spam-Status: No, score=-7.236 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+-69bM0AJTT for ; Wed, 2 Jun 2010 09:45:07 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E621728C161 for ; Wed, 2 Jun 2010 09:45:06 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAC4nBkyrR7Ht/2dsb2JhbACBP5xacacRmi+CV4I/BIJ+Sg X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="scan'208,217";a="138292776" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2010 16:44:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o52GisCJ029868; Wed, 2 Jun 2010 16:44:54 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 09:44:53 -0700 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_01CB0272.ED12F31F" Date: Wed, 2 Jun 2010 09:44:52 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01761048@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated charter/work description for telepresence multi-streams Thread-Index: AcsCckGWwU82fwSHRfKcAdGLrMuQTAAAIBTw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0176100E@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Peter Musgrave" X-OriginalArrivalTime: 02 Jun 2010 16:44:53.0905 (UTC) FILETIME=[ED2FC810:01CB0272] Cc: dispatch@ietf.org Subject: Re: [dispatch] Updated charter/work description for telepresence multi-streams 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, 02 Jun 2010 16:45:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0272.ED12F31F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, It's certainly possible imo to explicitly state RTP. We could put it on the list for changes, if there is no objection. =20 Allyn =20 From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: Wednesday, June 02, 2010 9:40 AM To: Allyn Romanow (allyn) Cc: dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings (fluffy) Subject: Re: [dispatch] Updated charter/work description for telepresence multi-streams =20 Hi,=20 =20 I read this through. I think it describes the work well enough at this point.=20 =20 Is it worth narrowing the scope of how media will be transmitted? I assume it will be RTP but this not explicitly stated. =20 Regards, =20 Peter Musgrave On Wed, Jun 2, 2010 at 12:11 PM, Allyn Romanow (allyn) wrote: Folks, Here is a version of the work description that addresses the comments made on the first draft.=20 The changes include:=20 1. Charter section, qualification that we are working on SIP-based systems 2. Charter section, minor word smithing 3. Charter section, reference to RAI WG with relevant work 4. Scope section, clarification of interoperability requirements 5. Scope section, replacement of second paragraph regarding treatment of non-video non-audio media types 6. Goals and Milestones - addition of a Problem Statement draft =20 =20 Comments welcome =20 Allyn =20 Multi-streams for Telepresence Description of Work =20 =20 =20 Background One branch of video conferencing has evolved that is focused on immersive "being there" experience. Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments. In recent years telepresence systems have seen considerable market success. Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones. These systems have several important characteristics that are different from more traditional video conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the miking and camera angles at each of the sites . This is distinct from the more traditional approach where the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve immersion. With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating and lighting so that when combined with large high quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is created. Typical video conference systems do not include these considerations. =20 As telepresence video systems have become successful in the market, manufacturers have started exploring delivery of the nonverbal communication and immersive values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, homes and kiosks. These are also telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, and large coordinated multi image displays are available for immersive installations. As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available. =20 Problem Although telepresence systems are based on open standards such as RTP, SIP, H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vendor to another. It would be like having to make sure all parties are on the same equipment (and network) when making a telephone call. A major factor in the inability of Telepresence systems to work with each other is that there is no standard description of the multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio streams sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability to present the remote participants at their true size for their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously providing a spatial audio sound stage consistent with the video presentation. The receiving device that decides how to display the incoming information needs to understand a number of variables such as the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media stream is related to each of the displays, etc.=20 =20 Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify for SIP-based systems the content of media multi-stream messages and the way these will be transported.=20 =20 This work will provide a standard for the exchange of media semantic information that will foster interoperable end stations and conference bridges. It will specify variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability. =20 This requires considering current widely deployed use cases, such as single and multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that are expected to be implemented using the protocol framework produced by this work item. The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technology and may have use cases that are not currently considered. =20 The work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required to be implemented to support this functionality. The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be required. =20 Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and FECframe. =20 Scope The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. =20 =20 The focus of this work is on audio and video multiple streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. =20 Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. =20 =20 =20 The group will produce - Requirements and use cases =20 - Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality required =20 - Specification of a new protocol to support telepresence multi-streams [if required] =20 Goals and Milestones Nov 2010=20 =20 Use Cases and Requirements to IESG as Informational RFC=20 Nov 2010 March 2011=20 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC=20 March 2011 Revise Charter [IF new protocol is not required] Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 =20 =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 ------_=_NextPart_001_01CB0272.ED12F31F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

It’s certainly possible imo to explicitly state = RTP. We could put it on the list for changes, if there is no = objection.

 

Allyn

 

From:= Peter = Musgrave [mailto:peter.musgrave@magorcorp.com]
Sent: Wednesday, June 02, 2010 9:40 AM
To: Allyn Romanow (allyn)
Cc: dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen = Jennings (fluffy)
Subject: Re: [dispatch] Updated charter/work description for = telepresence multi-streams

 

Hi, 

 

I read this through. I think it describes the work = well enough at this point. 

 

Is it worth narrowing the scope of how media will = be transmitted? I assume it will be RTP but this not explicitly = stated.

 

Regards,

 

Peter = Musgrave

On Wed, Jun 2, 2010 at 12:11 PM, Allyn Romanow = (allyn) <allyn@cisco.com> = wrote:

Folks,<= /o:p>

Here is a version of the work description that addresses the comments made on = the first draft.

The changes include:

1.       = Charter section, qualification that we are working on SIP-based = systems

2.       = Charter section, minor word smithing

3.       = Charter section, reference to RAI WG with relevant work

4.       = Scope section, clarification of interoperability requirements

5.       = Scope section, replacement of second paragraph regarding treatment of = non-video non-audio media types

6.       = Goals and Milestones – addition of a Problem Statement = draft

 <= /o:p>

 <= /o:p>

Comments welcome

 <= /o:p>

Allyn

 <= /o:p>

Multi-streams for Telepresence Description of = Work

 

 

 

Backgroun= d

One branch of video conferencing has evolved that is focused on immersive “being there” experience.  Referred to in various ways = such as virtual conferencing, telepresence or media spaces, early systems were = mainly research projects or business systems with limited deployments.  In = recent years telepresence systems have seen considerable market success.  Following the model of early systems, the first wave of commercial = systems have been typically located in specially designed single-purpose rooms with = multiple relatively large displays permitting life size image reproduction, = multiple cameras, encoders, decoders and microphones.  These systems have = several important characteristics that are different from more traditional video conferencing systems. 

 <= /o:p>

The first difference concerns controlling the visual viewpoint in order to = improve participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, seating = order and spatial audio by carefully orchestrating the miking and camera angles at = each of the sites . This is distinct from the more traditional approach where = the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. 

 <= /o:p>

A second difference is manipulation of the environment to improve = immersion.  With telepresence systems, cinematographic aspects of the local = environment reproduction are carefully planned including color, table shape, seating = and lighting so that when combined with large high quality displays, a = strong sense of a "trompe l'oeil" or "being there" immersive = experience is created.  Typical video conference systems do not include these considerations.

 <= /o:p>

As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal communication and = immersive values of telepresence via smaller, less expensive and more flexible = video conferencing systems for a variety of venues, such as individual = offices, homes and kiosks. These are also  telepresence systems, since the audio = and video quality is high enough to allow clear image reproduction for = nonverbal communication, they are able to send and receive multiple media streams, = and large coordinated multi image displays are available for immersive installations.   As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly = available.

 <= /o:p>

Problem

Although telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one = vendor to another. It would be like having to make sure all parties are on the = same equipment (and network) when making a telephone call.  A major = factor in the inability of Telepresence systems to work with each other is that = there is no standard description of the multiple streams that comprise the media = flows.

 <= /o:p>

For example, in a multiple screen conference, the video and audio streams = sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability = to present the remote participants at their true size for their apparent = distance, while maintaining correct eye contact, gesticular cues, and = simultaneously providing a spatial audio sound stage consistent with the video presentation.  The receiving device that decides how to display the incoming information needs to understand a number of variables such as = the spatial position of the speaker, the field of view of the cameras, the = camera zoom, which media stream is related to each of the displays, etc. =

 <= /o:p>

Charter

The Telepresence Multi-Streams work item in DISPATCH is chartered to define = and specify for SIP-based systems the content of media multi-stream messages = and the way these will be transported.

 <= /o:p>

This work will provide a standard for the exchange = of media semantic information that will foster interoperable end stations = and conference bridges. It will specify  variables that describe the = semantics of the media streams and the recommended behavior to achieve interoperability. 

 

This requires considering current widely deployed = use cases, such as single and multiple screens, multi-point, Scalable Video = Coding (SVC), as well as cases that are expected to be implemented using the = protocol framework produced by this work item.  The methodology for = describing the variables must allow extensibility of the variables, since telepresence = is still a young technology and may have use cases that are not currently considered.

 <= /o:p>

The work item will identify use cases, define requirements, and define a method for describing and transporting = information about multiple media streams, including a specification of variables = required to support the use cases. This work item will consider the reuse of = existing IETF protocols and produce an architecture/protocol framework document = describing the protocols required to be implemented to support this = functionality.  The document will identify any enhancements required to existing = protocols as well as describing new protocol(s) for interoperable multi-streams = negotiation that may be required.

 

Relevant work to be drawn upon has been done in = XCON, MMUSIC, AVT, and FECframe.

 

Scope

The scope includes both systems that provide a fully immersive experience, = and systems that interwork with them and therefore need to understand the = same multiple stream semantics.

 <= /o:p>

 

The focus of this work is on audio and video multiple streams.  = Other media types may be considered, however development of methodologies for = them is not within the scope of this work.

 

Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems.  However, backwards compatibility with existing non-standards compliant = telepresence systems is not required.

 

 

 

The group will produce

- Requirements and use cases

 

- Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality = required

 

- Specification of a new protocol to support = telepresence multi-streams [if required]

 <= /o:p>

Goals and Milestones

Nov 2010

 <= /o:p>

Use Cases and Requirements to IESG as Informational RFC

Nov 2010

March 2011

Problem Statement to IESG as Informational RFC

Architecture= to IESG as Informational RFC

March 2011

Revise Charter [IF new protocol is not required]

Nov 2011

Submit protocol draft to IESG as Proposed Standard RFC

 <= /o:p>

 <= /o:p>

 <= /o:p>


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

 

------_=_NextPart_001_01CB0272.ED12F31F-- From fluffy@cisco.com Wed Jun 2 11:30:24 2010 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 CBF9A3A68D0 for ; Wed, 2 Jun 2010 11:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.671 X-Spam-Level: X-Spam-Status: No, score=-107.671 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 IooOWTejNLtG for ; Wed, 2 Jun 2010 11:30:23 -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 5C8AA3A67A4 for ; Wed, 2 Jun 2010 11:30:11 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="scan'208";a="538886191" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2010 18:29:55 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o52ITsRt012032; Wed, 2 Jun 2010 18:29:54 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <1D062974A4845E4D8A343C653804920202D4450A@XMB-BGL-414.cisco.com> Date: Wed, 2 Jun 2010 12:29:53 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <1D062974A4845E4D8A343C653804920202D4450A@XMB-BGL-414.cisco.com> To: Muthu ArulMozhi Perumal (mperumal) X-Mailer: Apple Mail (2.1078) Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) 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, 02 Jun 2010 18:30:24 -0000 Good catch - we certainly want it to just be one of many ways. On Jun 1, 2010, at 12:12 PM, Muthu ArulMozhi Perumal (mperumal) wrote: > |The goal of this working group is to allows people to use SIP to > |federate over the the internet while still using phone numbers to > |identify the person they wish to communicate with. > > Do we want to use phone numbers as the only way to identify persons or > allow people to use phone numbers as one of the ways to identify > persons? > > If it is the later, should we reword "still using phone numbers to > identify" as "still allowing phone numbers to identify"? > > thanks, > Muthu > > |-----Original Message----- > |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > |Of Cullen Jennings (fluffy) > |Sent: Tuesday, June 01, 2010 10:25 PM > |To: DISPATCH list > |Subject: [dispatch] Charter Proposal: Verification Involving > |PSTNReachability (VIPR) > | > | > |I've been talking to a lot of people about the VIPR drafts - here is a > |first cut of a proposal for a WG that could do this. I'm sure the > charter > |proposal needs a bunch of work but I wanted to get the discussion > rolling on > |the list. > | > |Thanks, Cullen > | > |(PS - this is sent in my individual contributor role. Take all my posts > |about VIPR to be in my individual role not my co-chair role) > | > |------------------------------------------------------- > | > |ViPR Charter Proposal (Version 0) > | > |WG Name: Verification Involving PSTN Reachability (VIPR) > | > |There are two globally deployed address spaces for communications that > more > |than a billion people use on a daily basis. They are phone numbers and > DNS > |rooted address such as web servers and email addresses. The federation > |design of SIP is primarily designed for email style addresses yet a > large > |percentage of SIP deployments primarily use phone numbers for > identifying > |users. The goal of this working group is to allows people to use SIP to > |federate over the the internet while still using phone numbers to > identify > |the person they wish to communicate with. > | > |The VIPR WG will address this problem by developing a peer to peer > based > |approach to finding SIP domains that claim to be responsible for a > given > |phone number and the WG will design validation protocols to ensure a > |reasonable likelihood that a given domain actually is responsible for > the > |phone number. One initial validation protocol will be based on a domain > |being able to prove it received a particular phone call over the PSTN > based > |on both sides knowing the start and stop times of that call. Other > |validation schemes, such as examining fingerprints or watermarking of > PSTN > |media, to show that a domain received a particular PSTN phone call may > be > |considered by the working group. To help mitigate SPAM over SIP issues, > the > |WG will define an token based authorization scheme so that domain using > SIP > |to federate can choose to check that incoming SIP calls are from a > domain > |that successfully validated a phone number. > | > |The problem statement and some possible starting points for solutions > are > |further desired in the following internet drafts which shall form the > bases > |of the WG documents: > |draft-rosenberg-dispatch-vipr-overview > |draft-rosenberg-dispatch-vipr-reload-usage > |draft-rosenberg-dispatch-vipr-pvp > |draft-rosenberg-dispatch-vipr-sip-antispam > | > |The working group will carefully coordinate with the security area, O&M > |area, as well as the appropriate RAI WG including sipcore and p2psip. > | > | > |_______________________________________________ > |dispatch mailing list > |dispatch@ietf.org > |https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From petithug@acm.org Wed Jun 2 11:31:38 2010 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 088333A6A16 for ; Wed, 2 Jun 2010 11:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.85 X-Spam-Level: X-Spam-Status: No, score=-99.85 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 e1uxVGeU7m83 for ; Wed, 2 Jun 2010 11:31:30 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 958C628C0F1 for ; Wed, 2 Jun 2010 11:31:27 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 8D82BDBD401C; Wed, 2 Jun 2010 18:31:10 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 8C3EBDBD4018; Wed, 2 Jun 2010 18:31:09 +0000 (UTC) Message-ID: <4C06A36B.3090103@acm.org> Date: Wed, 02 Jun 2010 11:31:07 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Iceowl/1.0b1 Icedove/3.0.4 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 18:31:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/01/2010 09:55 AM, Cullen Jennings wrote: > > I've been talking to a lot of people about the VIPR drafts - here is a first cut of a proposal for a WG that could do this. I'm sure the charter proposal needs a bunch of work but I wanted to get the discussion rolling on the list. > > Thanks, Cullen > > (PS - this is sent in my individual contributor role. Take all my posts about VIPR to be in my individual role not my co-chair role) > > ------------------------------------------------------- > > ViPR Charter Proposal (Version 0) > > WG Name: Verification Involving PSTN Reachability (VIPR) > > There are two globally deployed address spaces for communications that more than a billion people use on a daily basis. They are phone numbers and DNS rooted address such as web servers and email addresses. The federation design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments primarily use phone numbers for identifying users. The goal of this working group is to allows people to use SIP to federate over the the internet while still using phone numbers to identify the person they wish to communicate with. > > The VIPR WG will address this problem by developing a peer to peer based approach to finding SIP domains that claim to be responsible for a given phone number and the WG will design validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. One initial validation protocol will be based on a domain being able to prove it received a particular phone call over the PSTN based on both sides knowing the start and stop times of that call. Other validation schemes, such as examining fingerprints or watermarking of PSTN media, to show that a domain received a particular PSTN phone call may be considered by the working group. To help mitigate SPAM over SIP issues, the WG will define an token based authorization scheme so that domain using SIP to federate can choose to check that incoming SIP calls are from a domain that successfully validated a phone number. > > The problem statement and some possible starting points for solutions are further desired in the following internet drafts which shall form the bases of the WG documents: > draft-rosenberg-dispatch-vipr-overview > draft-rosenberg-dispatch-vipr-reload-usage > draft-rosenberg-dispatch-vipr-pvp > draft-rosenberg-dispatch-vipr-sip-antispam VAP is not listed here. Is it an oversight or is it because the WG will work only on interoperability between ViPR servers? > > The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WG including sipcore and p2psip. I think something should said about the fact that ViPR requires SIP over (D)TLS and SRTP, as it is, IMO, an important characteristic of ViPR. Also there is perhaps a need to define a minimal subset of SIP extensions and media capabilities for ViPR. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwGo2cACgkQ9RoMZyVa61dVxQCfXy3+nrcwUg3oEhvr4+m93ZoK hvcAmwUEVsRUJIcbisrNQt0tg2mAEwkC =GSeb -----END PGP SIGNATURE----- From fluffy@cisco.com Wed Jun 2 11:36:03 2010 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 8DF5F28C16B for ; Wed, 2 Jun 2010 11:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.396 X-Spam-Level: X-Spam-Status: No, score=-108.396 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 UsYiN0CrhuGQ for ; Wed, 2 Jun 2010 11:35:58 -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 D3A2928C161 for ; Wed, 2 Jun 2010 11:35:56 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPdABkyrR7H+/2dsb2JhbACeHnGnI5ojgleCPwSDSA X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="scan'208";a="206096065" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 02 Jun 2010 18:35:35 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o52IZYEL003426; Wed, 2 Jun 2010 18:35:35 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 2 Jun 2010 12:35:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <33870CEC-3737-4070-8880-18ED4818D82F@cisco.com> References: To: Peter Musgrave X-Mailer: Apple Mail (2.1078) Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 18:36:03 -0000 I kept trying to write something about the relation of ViPR to ENUM but = it kept coming out sounding like public ENUM had failed - which was not = really what I wanted to say so I eventually deleted it. If someone had = some good text about ENUM, would be nice to add it.=20 I view infrastructure and carrier ENUM as somewhat unrelated to this but = public ENUM is related. However, ENUM talks about how to query the = database, but it is somewhat silent on how data gets in the database. = How does the database authorize that someone is authoritative for a = number and can put write a record into the ENUM database. VIPR is more = about that side of the problem.=20 And +1 to Paul's answers of the other questions .... On Jun 1, 2010, at 12:28 PM, Peter Musgrave wrote: > Hi Cullen, >=20 > Does the charter need to say anything explicitly about not relying on > any of the work which uses ENUMs in DNS as a way of associating SIP > endpoints and IP addresses? >=20 > AFAIK ViPR is about *using* a SIP call to determine a path to the > endpoint (however that happens to work). >=20 > Does the charter need to stipulate that the mapping from a PSTN number > to a SIP device is a one-to-one mapping? Does there need to be text > about how multiple endpoints which are behind a border device (and all > appear as the same PSTN number) are to be handled?. >=20 > ViPR so far describes an "edge-device" approach. Is the charter > restricted to this approach? >=20 > Thanks, >=20 > Peter Musgrave >=20 >=20 >=20 > On Tue, Jun 1, 2010 at 12:55 PM, Cullen Jennings = wrote: > > > > I've been talking to a lot of people about the VIPR drafts - here = is a first cut of a proposal for a WG that could do this. I'm sure the = charter proposal needs a bunch of work but I wanted to get the = discussion rolling on the list. > > > > Thanks, Cullen > > > > (PS - this is sent in my individual contributor role. Take all my = posts about VIPR to be in my individual role not my co-chair role) > > > > ------------------------------------------------------- > > > > ViPR Charter Proposal (Version 0) > > > > WG Name: Verification Involving PSTN Reachability (VIPR) > > > > There are two globally deployed address spaces for communications = that more than a billion people use on a daily basis. They are phone = numbers and DNS rooted address such as web servers and email addresses. = The federation design of SIP is primarily designed for email style = addresses yet a large percentage of SIP deployments primarily use phone = numbers for identifying users. The goal of this working group is to = allows people to use SIP to federate over the the internet while still = using phone numbers to identify the person they wish to communicate = with. > > > > The VIPR WG will address this problem by developing a peer to peer = based approach to finding SIP domains that claim to be responsible for a = given phone number and the WG will design validation protocols to ensure = a reasonable likelihood that a given domain actually is responsible for = the phone number. One initial validation protocol will be based on a = domain being able to prove it received a particular phone call over the = PSTN based on both sides knowing the start and stop times of that call. = Other validation schemes, such as examining fingerprints or watermarking = of PSTN media, to show that a domain received a particular PSTN phone = call may be considered by the working group. To help mitigate SPAM over = SIP issues, the WG will define an token based authorization scheme so = that domain using SIP to federate can choose to check that incoming SIP = calls are from a domain that successfully validated a phone number. > > > > The problem statement and some possible starting points for = solutions are further desired in the following internet drafts which = shall form the bases of the WG documents: > > draft-rosenberg-dispatch-vipr-overview > > draft-rosenberg-dispatch-vipr-reload-usage > > draft-rosenberg-dispatch-vipr-pvp > > draft-rosenberg-dispatch-vipr-sip-antispam > > > > The working group will carefully coordinate with the security area, = O&M area, as well as the appropriate RAI WG including sipcore and = p2psip. > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jun 2 11:39:26 2010 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 D711D28C17A for ; Wed, 2 Jun 2010 11:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.66 X-Spam-Level: X-Spam-Status: No, score=-109.66 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 LjivWrFQ8fYp for ; Wed, 2 Jun 2010 11:39:26 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DF61B3A6A24 for ; Wed, 2 Jun 2010 11:39:24 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACNCBkyrR7H+/2dsb2JhbACeHnGnOZojhRYEg0g X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="scan'208";a="138324878" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2010 18:39:12 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o52IdBCY006334; Wed, 2 Jun 2010 18:39:12 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 2 Jun 2010 12:39:11 -0600 Content-Transfer-Encoding: 7bit Message-Id: <348C248A-064E-48D9-AAE7-04A9561D16D7@cisco.com> References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1078) Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym 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, 02 Jun 2010 18:39:26 -0000 +1 to ALES or SALUD From peter.musgrave@magorcorp.com Wed Jun 2 11:50:35 2010 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 9A2E93A6359 for ; Wed, 2 Jun 2010 11:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OETteVeLZMgJ for ; Wed, 2 Jun 2010 11:50:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id CA20B28C190 for ; Wed, 2 Jun 2010 11:49:52 -0700 (PDT) Received: by gyh4 with SMTP id 4so5015531gyh.31 for ; Wed, 02 Jun 2010 11:49:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.114.1 with SMTP id m1mr7670713ybc.354.1275504576726; Wed, 02 Jun 2010 11:49:36 -0700 (PDT) Received: by 10.150.199.12 with HTTP; Wed, 2 Jun 2010 11:49:36 -0700 (PDT) In-Reply-To: <33870CEC-3737-4070-8880-18ED4818D82F@cisco.com> References: <33870CEC-3737-4070-8880-18ED4818D82F@cisco.com> Date: Wed, 2 Jun 2010 14:49:36 -0400 Message-ID: From: Peter Musgrave To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 18:50:35 -0000 How about: "The essential characteristic of ViPR is establishing authentication by PSTN reachability and not by e.g. direct reference to ENUM databases or other assertions of PSTN number ownership. Elements such as public ENUM may be employed indirectly as part of assessing the PSTN reachability but no direct interaction with ENUM will be required. " Peter On Wed, Jun 2, 2010 at 2:35 PM, Cullen Jennings wrote: > > I kept trying to write something about the relation of ViPR to ENUM but i= t kept coming out sounding like public ENUM had failed - which was not real= ly what I wanted to say so I eventually deleted it. If someone had some goo= d text about ENUM, would be nice to add it. > > I view infrastructure and carrier ENUM as somewhat unrelated to this but = public ENUM is related. However, ENUM talks about how to query the database= , but it is somewhat silent on how data gets in the database. How does the = database authorize that someone is authoritative for a number and can put w= rite a record into the ENUM database. VIPR is more about that side of the p= roblem. > > And +1 to Paul's answers of the other questions .... > > On Jun 1, 2010, at 12:28 PM, Peter Musgrave wrote: > >> Hi Cullen, >> >> Does the charter need to say anything explicitly about not relying on >> any of the work which uses ENUMs in DNS as a way of associating SIP >> endpoints and IP addresses? >> >> AFAIK ViPR is about *using* a SIP call to determine a path to the >> endpoint (however that happens to work). >> >> Does the charter need to stipulate that the mapping from a PSTN number >> to a SIP device is a one-to-one mapping? Does there need to be text >> about how multiple endpoints which are behind a border device (and all >> appear as the same PSTN number) are to be handled?. >> >> ViPR so far describes an "edge-device" approach. Is the charter >> restricted to this approach? >> >> Thanks, >> >> Peter Musgrave >> >> >> >> On Tue, Jun 1, 2010 at 12:55 PM, Cullen Jennings wrot= e: >> > >> > I've been talking to a lot of people about the VIPR drafts =A0- here i= s a first cut of a proposal for a WG that could do this. I'm sure the chart= er proposal needs a bunch of work but I wanted to get the discussion rollin= g on the list. >> > >> > Thanks, Cullen >> > >> > (PS - this is sent in my individual contributor role. Take all my post= s about VIPR to be in my individual role not my co-chair role) >> > >> > ------------------------------------------------------- >> > >> > ViPR Charter Proposal (Version 0) >> > >> > WG Name: =A0Verification Involving PSTN Reachability (VIPR) >> > >> > There are two globally deployed address spaces for communications that= more than a billion people use on a daily basis. They are phone numbers an= d DNS rooted address such as web servers and email addresses. The federatio= n design of SIP is primarily designed for email style addresses yet a large= percentage of SIP deployments primarily use phone numbers for identifying = users. The goal of this working group is to allows people to use SIP to fed= erate over the the internet while still using phone numbers to identify the= person they wish to communicate with. >> > >> > The VIPR WG will address this problem by developing a peer to peer bas= ed approach to finding SIP domains that claim to be responsible for a given= phone number and the WG will design validation protocols to ensure a reaso= nable likelihood that a given domain actually is responsible for the phone = number. One initial validation protocol will be based on a domain being abl= e to prove it received a particular phone call over the PSTN based on both = sides knowing the start and stop times of that call. Other validation schem= es, such as examining fingerprints or watermarking of PSTN media, to show t= hat a domain received a particular PSTN phone call may be considered by the= working group. To help mitigate SPAM over SIP issues, the WG will define a= n token based authorization scheme so that domain using SIP to federate can= choose to check that incoming SIP calls are from a domain that successfull= y validated a phone number. >> > >> > The problem statement and some possible starting points for solutions = are further desired in the following internet drafts which shall form the b= ases of the WG documents: >> > draft-rosenberg-dispatch-vipr-overview >> > draft-rosenberg-dispatch-vipr-reload-usage >> > draft-rosenberg-dispatch-vipr-pvp >> > draft-rosenberg-dispatch-vipr-sip-antispam >> > >> > The working group will carefully coordinate with the security area, O&= M area, as well as the appropriate RAI WG including sipcore and p2psip. >> > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > >> > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > From fluffy@cisco.com Wed Jun 2 11:56:42 2010 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 3FBF13A6858 for ; Wed, 2 Jun 2010 11:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.835 X-Spam-Level: X-Spam-Status: No, score=-107.835 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 0afo8buQtgWW for ; Wed, 2 Jun 2010 11:56:41 -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 1BA4C3A683F for ; Wed, 2 Jun 2010 11:56:41 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB5GBkyrRN+K/2dsb2JhbACeHnGnNZomgleCPwSDSA X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="scan'208";a="331631385" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 02 Jun 2010 18:56:25 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o52IuONu026424; Wed, 2 Jun 2010 18:56:24 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> Date: Wed, 2 Jun 2010 12:56:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> To: "Patel, Milan" X-Mailer: Apple Mail (2.1078) Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI 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, 02 Jun 2010 18:56:42 -0000 Can we identify the complete list of semantic information this WG would = cover? Some working groups have tried to charter with just "some = information" and it is so vague that it really slows down the WG.=20 Then can we look at at least one real world use case for each type of = information - Take the pay phone case for example, what is the use case = where someone needs to know the other end is a pay phone and what do = they do differently. On May 28, 2010, at 7:13 AM, Patel, Milan wrote: > Hello, > =20 > Attached is a charter proposal for a WG to be formed for work = pertaining to extensions to the tel URI =96 specifically, parameters for = carrying the DAI, CPC, OLI and RN required for primarily interworking = scenarios to ISUP/PSTN. > Feedback is appreciated. > Regards, > Milan > =20 > =20 > From: Patel, Milan=20 > Sent: Tuesday, May 25, 2010 11:16 AM > To: Cullen Jennings; 'mary.ietf.barnes@gmail.com'; Robert Sparks; = 'Gonzalo Camarillo' > Cc: R.Jesske@telekom.de; 'Sumanth Channabasappa' > Subject: Charter proposal > =20 > Hi all, > =20 > Attached is a charter proposal for a WG to be formed to handle = Internet Drafts pertaining to the Tel URI. Specifically these are the = DAI draft and the CPC/OLI draft and some further work on the RN = parameter. > Feedback is welcome. > =20 > Kind regards, > Milan > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jun 2 12:00:08 2010 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 443513A67E9 for ; Wed, 2 Jun 2010 12:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.19 X-Spam-Level: X-Spam-Status: No, score=-109.19 tagged_above=-999 required=5 tests=[AWL=1.409, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 yrI4QeTCKBkn for ; Wed, 2 Jun 2010 12:00:06 -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 8390E3A6A43 for ; Wed, 2 Jun 2010 12:00:06 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEpHBkyrRN+K/2dsb2JhbACeHnGnQJonhRYEg0g X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="scan'208";a="259546400" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2010 18:59:53 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o52Ixqre027952; Wed, 2 Jun 2010 18:59:53 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 2 Jun 2010 12:59:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <48A9B894-839B-40F8-BE0E-1817FA6B2597@cisco.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0155CE48@xmb-sjc-221.amer.cisco.com> To: stephen botzko X-Mailer: Apple Mail (2.1078) Cc: dispatch@ietf.org, Markus.Isomaki@nokia.com Subject: Re: [dispatch] Multi-streams for telepresence description of work 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, 02 Jun 2010 19:00:08 -0000 On May 19, 2010, at 5:19 AM, stephen botzko wrote: > Allyn and I co-chair the IMTC multi-streaming group. The IMTC would = be delighted if the IETF takes on this work item. And at some time in the past, the RAI ADs told IMTC that they would be = delighted to see the IMTC bring this type of work to the IETF. From hakon.dahle@tandberg.com Wed Jun 2 12:24:15 2010 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 9D0E828C0E9 for ; Wed, 2 Jun 2010 12:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.527 X-Spam-Level: X-Spam-Status: No, score=-4.527 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.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 MA0PdBAru5pr for ; Wed, 2 Jun 2010 12:24:04 -0700 (PDT) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by core3.amsl.com (Postfix) with SMTP id CC7D33A68AD for ; Wed, 2 Jun 2010 12:24:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: hakon.dahle@tandberg.com X-Msg-Ref: server-5.tower-194.messagelabs.com!1275506628!28958188!2 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 19736 invoked from network); 2 Jun 2010 19:23:49 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-5.tower-194.messagelabs.com with SMTP; 2 Jun 2010 19:23:49 -0000 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 21:23:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0289.201B0373" Date: Wed, 2 Jun 2010 21:23:46 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB086D58C0@oslexcp1.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated charter/work description for telepresence multi-streams Thread-Index: AcsCg78Xe5vMg33eTiSU7YqhqpXicQABSqBA From: =?iso-8859-1?Q?H=E5kon_Dahle?= To: X-OriginalArrivalTime: 02 Jun 2010 19:23:48.0501 (UTC) FILETIME=[203FAC50:01CB0289] Subject: Re: [dispatch] Updated charter/work description for telepresence multi-streams 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, 02 Jun 2010 19:24:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0289.201B0373 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A comment on the following sentence in the updated charter: =20 "This requires considering current widely deployed use cases, such as = single and multiple screens, multi-point, Scalable Video Coding (SVC), = as well as cases that are expected to be implemented using the protocol = framework produced by this work item. " =20 Addressing use cases such as single and multiple screen systems, as well = as both point-to-point and multi-point calling is great. However I do = not understand why a specific video codec or coding technique has been = added to the same context. The charter shouldn't recommend or limit the = work for any specific codec (it should be codec agnostic), and I = suggest the charter should be changed to comply with this. =20 =20 -h =20 ________________________________ Fra: dispatch-bounces@ietf.org p=E5 vegne av Allyn Romanow (allyn) Sendt: on 02.06.2010 18:11 Til: dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings = (fluffy) Emne: [dispatch] Updated charter/work description for = telepresencemulti-streams Folks, Here is a version of the work description that addresses the comments = made on the first draft.=20 The changes include:=20 1. Charter section, qualification that we are working on SIP-based = systems 2. Charter section, minor word smithing 3. Charter section, reference to RAI WG with relevant work 4. Scope section, clarification of interoperability requirements 5. Scope section, replacement of second paragraph regarding = treatment of non-video non-audio media types 6. Goals and Milestones - addition of a Problem Statement draft =20 =20 Comments welcome =20 Allyn =20 Multi-streams for Telepresence Description of Work =20 =20 =20 Background One branch of video conferencing has evolved that is focused on = immersive "being there" experience. Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were = mainly research projects or business systems with limited deployments. = In recent years telepresence systems have seen considerable market = success. Following the model of early systems, the first wave of = commercial systems have been typically located in specially designed = single-purpose rooms with multiple relatively large displays permitting = life size image reproduction, multiple cameras, encoders, decoders and = microphones. These systems have several important characteristics that = are different from more traditional video conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order = to improve participant nonverbal communication. These systems preserve = essential group meeting characteristics such as eye contact, group = gestures, seating order and spatial audio by carefully orchestrating the = miking and camera angles at each of the sites . This is distinct from = the more traditional approach where the geometric relationship between = media streams is not used to preserve inter-stream communication aspects = such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve = immersion. With telepresence systems, cinematographic aspects of the = local environment reproduction are carefully planned including color, = table shape, seating and lighting so that when combined with large high = quality displays, a strong sense of a "trompe l'oeil" or "being there" = immersive experience is created. Typical video conference systems do = not include these considerations. =20 As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal = communication and immersive values of telepresence via smaller, less = expensive and more flexible video conferencing systems for a variety of = venues, such as individual offices, homes and kiosks. These are also = telepresence systems, since the audio and video quality is high enough = to allow clear image reproduction for nonverbal communication, they are = able to send and receive multiple media streams, and large coordinated = multi image displays are available for immersive installations. As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available. =20 Problem Although telepresence systems are based on open standards such as RTP, = SIP, H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call. A major factor in the inability of Telepresence systems = to work with each other is that there is no standard description of the = multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio = streams sent from remote participants must be understood by receivers so = that they can be presented in a coherent and life-like manner. This = includes the ability to present the remote participants at their true = size for their apparent distance, while maintaining correct eye contact, = gesticular cues, and simultaneously providing a spatial audio sound = stage consistent with the video presentation. The receiving device that = decides how to display the incoming information needs to understand a = number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is = related to each of the displays, etc.=20 =20 Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to = define and specify for SIP-based systems the content of media = multi-stream messages and the way these will be transported.=20 =20 This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference = bridges. It will specify variables that describe the semantics of the = media streams and the recommended behavior to achieve interoperability. = =20 This requires considering current widely deployed use cases, such as = single and multiple screens, multi-point, Scalable Video Coding (SVC), = as well as cases that are expected to be implemented using the protocol = framework produced by this work item. The methodology for describing = the variables must allow extensibility of the variables, since = telepresence is still a young technology and may have use cases that are = not currently considered. =20 The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media = streams, including a specification of variables required to support the = use cases. This work item will consider the reuse of existing IETF = protocols and produce an architecture/protocol framework document = describing the protocols required to be implemented to support this = functionality. The document will identify any enhancements required to = existing protocols as well as describing new protocol(s) for = interoperable multi-streams negotiation that may be required. =20 Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe. =20 Scope The scope includes both systems that provide a fully immersive = experience, and systems that interwork with them and therefore need to = understand the same multiple stream semantics. =20 =20 The focus of this work is on audio and video multiple streams. Other = media types may be considered, however development of methodologies for = them is not within the scope of this work. =20 Interoperation with standards compliant systems is required, such as = SIP-based video conferencing systems. However, backwards compatibility = with existing non-standards compliant telepresence systems is not = required. =20 =20 =20 The group will produce - Requirements and use cases =20 - Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing = protocol enhancements and new protocol functionality required =20 - Specification of a new protocol to support telepresence multi-streams = [if required] =20 Goals and Milestones Nov 2010=20 =20 Use Cases and Requirements to IESG as Informational RFC=20 Nov 2010 March 2011=20 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC=20 March 2011 Revise Charter [IF new protocol is not required] Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 =20 =20 ------_=_NextPart_001_01CB0289.201B0373 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A comment on the following = sentence in the updated charter:

 

“This requires considering current = widely deployed use cases, such as single and multiple screens, = multi-point, Scalable Video Coding (SVC), as well as cases that are = expected to be implemented using the protocol framework produced by this = work item.  ”

 

Addressing = use cases such as single and multiple screen systems, as well as both = point-to-point and multi-point calling is great.  However I do not = understand why a specific video codec or coding technique has been added = to the same context.  The charter shouldn’t recommend or = limit the work for any specific codec (it should be codec = agnostic),  and I suggest the charter should be changed to comply = with this. 

 

-h

 

Fra:<= /b> = dispatch-bounces@ietf.org p=E5 vegne av Allyn Romanow = (allyn)
Sendt: on 02.06.2010 18:11
Til: = dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings = (fluffy)
Emne: [dispatch] Updated charter/work description for = telepresencemulti-streams

Folks,

Here is a version of the work description that addresses = the comments made on the first draft.

The changes include: =

1.       Charter section, qualification that we are working on = SIP-based systems

2.       Charter section, minor word = smithing

3.       Charter section, reference to RAI WG with relevant = work

4.       Scope section, clarification of interoperability = requirements

5.       Scope section, replacement of second paragraph regarding = treatment of non-video non-audio media types

6.       Goals and Milestones – addition of a Problem = Statement draft

 

 

Comments welcome

 

Allyn

 

Multi-streams = for Telepresence Description of Work

 

 

 

Background

One branch of = video conferencing has evolved that is focused on immersive “being = there” experience.  Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were = mainly research projects or business systems with limited = deployments.  In recent years telepresence systems have seen = considerable market success.  Following the model of early systems, = the first wave of commercial systems have been typically located in = specially designed single-purpose rooms with multiple relatively large = displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones.  These systems have several = important characteristics that are different from more traditional video = conferencing systems. 

 

The first = difference concerns controlling the visual viewpoint in order to improve = participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, = seating order and spatial audio by carefully orchestrating the miking = and camera angles at each of the sites . This is distinct from the more = traditional approach where the geometric relationship between media = streams is not used to preserve inter-stream communication aspects such = as eye contact and group dynamics. 

 

A second = difference is manipulation of the environment to improve = immersion.  With telepresence systems, cinematographic aspects of = the local environment reproduction are carefully planned including = color, table shape, seating and lighting so that when combined with = large high quality displays, a strong sense of a "trompe = l'oeil" or "being there" immersive experience is = created.  Typical video conference systems do not include these = considerations.

 

As telepresence video systems = have become successful in the market, manufacturers have started = exploring delivery of the nonverbal communication and immersive values = of telepresence via smaller, less expensive and more flexible video = conferencing systems for a variety of venues, such as individual = offices, homes and kiosks. These are also  telepresence systems, = since the audio and video quality is high enough to allow clear image = reproduction for nonverbal communication, they are able to send and = receive multiple media streams, and large coordinated multi image = displays are available for immersive installations.   As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available.

 

Problem

Although = telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call.  A major factor in the inability of Telepresence = systems to work with each other is that there is no standard description = of the multiple streams that comprise the media flows.

 

For example, in = a multiple screen conference, the video and audio streams sent from = remote participants must be understood by receivers so that they can be = presented in a coherent and life-like manner. This includes the ability = to present the remote participants at their true size for their apparent = distance, while maintaining correct eye contact, gesticular cues, and = simultaneously providing a spatial audio sound stage consistent with the = video presentation.  The receiving device that decides how to = display the incoming information needs to understand a number of = variables such as the spatial position of the speaker, the field of view = of the cameras, the camera zoom, which media stream is related to each = of the displays, etc.

 

Charter

The Telepresence = Multi-Streams work item in DISPATCH is chartered to define and specify = for SIP-based systems the content of media multi-stream messages and the = way these will be transported.

 

This work will = provide a standard for the exchange of media semantic information that = will foster interoperable end stations and conference bridges. It will = specify  variables that describe the semantics of the media streams = and the recommended behavior to achieve interoperability.  =

 

This requires considering = current widely deployed use cases, such as single and multiple screens, = multi-point, Scalable Video Coding (SVC), as well as cases that are = expected to be implemented using the protocol framework produced by this = work item.  The methodology for describing the variables must allow = extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently = considered.

 

The work item will identify = use cases, define requirements, and define a method for describing and = transporting information about multiple media streams, including a = specification of variables required to support the use cases. This work = item will consider the reuse of existing IETF protocols and produce an = architecture/protocol framework document describing the protocols = required to be implemented to support this functionality.  The = document will identify any enhancements required to existing protocols = as well as describing new protocol(s) for interoperable multi-streams = negotiation that may be required.

 

Relevant work to = be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe.

 

Scope

The scope = includes both systems that provide a fully immersive experience, and = systems that interwork with them and therefore need to understand the = same multiple stream semantics.

 

 

The focus of = this work is on audio and video multiple streams.  Other media = types may be considered, however development of methodologies for them = is not within the scope of this work.

 

Interoperation = with standards compliant systems is required, such as SIP-based video = conferencing systems.  However, backwards compatibility with = existing non-standards compliant telepresence systems is not = required.

 

 

 

The group will = produce

- Requirements and use = cases

 

- Architectural Framework = describing the protocols required to be implemented to support this = functionality and identifying existing protocol enhancements and new = protocol functionality required

 

- Specification = of a new protocol to support telepresence multi-streams [if = required]

 

Goals and = Milestones

Nov = 2010

 

Use Cases and Requirements to = IESG as Informational RFC

Nov = 2010

March 2011 =

Problem Statement to IESG as = Informational RFC

Architecture to IESG as = Informational RFC

March = 2011

Revise Charter [IF new = protocol is not required]

Nov = 2011

Submit protocol draft to IESG = as Proposed Standard RFC

 

 

 

------_=_NextPart_001_01CB0289.201B0373-- From hakon.dahle@tandberg.com Wed Jun 2 11:52:24 2010 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 E659828C17E for ; Wed, 2 Jun 2010 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.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 xb2sLdZefs1L for ; Wed, 2 Jun 2010 11:52:11 -0700 (PDT) Received: from mail205.messagelabs.com (mail205.messagelabs.com [85.158.140.179]) by core3.amsl.com (Postfix) with SMTP id 5A38228C177 for ; Wed, 2 Jun 2010 11:52:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: hakon.dahle@tandberg.com X-Msg-Ref: server-16.tower-205.messagelabs.com!1275504716!29747363!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 6416 invoked from network); 2 Jun 2010 18:51:56 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-16.tower-205.messagelabs.com with SMTP; 2 Jun 2010 18:51:56 -0000 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 20:51:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0284.AC864E53" Date: Wed, 2 Jun 2010 20:51:54 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB086D58B3@oslexcp1.eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated charter/work description for telepresence multi-streams Thread-Index: AcsCg78Xe5vMg33eTiSU7YqhqpXicQ== From: =?iso-8859-1?Q?H=E5kon_Dahle?= To: X-OriginalArrivalTime: 02 Jun 2010 18:51:56.0695 (UTC) FILETIME=[ACB93A70:01CB0284] X-Mailman-Approved-At: Wed, 02 Jun 2010 13:06:02 -0700 Subject: Re: [dispatch] Updated charter/work description for telepresence multi-streams 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, 02 Jun 2010 18:54:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0284.AC864E53 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A comment on the following sentence in the updated charter: =20 "This requires considering current widely deployed use cases, such as = single and multiple screens, multi-point, Scalable Video Coding (SVC), = as well as cases that are expected to be implemented using the protocol = framework produced by this work item. " =20 Addressing use cases such as single and multiple screen systems, as well = as both point-to-point and multi-point calling is great. However I do = not understand why a specific video codec or coding technique has been = added to the same context. The charter shouldn't recommend or limit the = work for any specific codec (it should be codec agnostic), and I = suggest the charter should be changed to comply with this. =20 =20 -h =20 ________________________________ Fra: dispatch-bounces@ietf.org p=E5 vegne av Allyn Romanow (allyn) Sendt: on 02.06.2010 18:11 Til: dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings = (fluffy) Emne: [dispatch] Updated charter/work description for = telepresencemulti-streams Folks, Here is a version of the work description that addresses the comments = made on the first draft.=20 The changes include:=20 1. Charter section, qualification that we are working on SIP-based = systems 2. Charter section, minor word smithing 3. Charter section, reference to RAI WG with relevant work 4. Scope section, clarification of interoperability requirements 5. Scope section, replacement of second paragraph regarding = treatment of non-video non-audio media types 6. Goals and Milestones - addition of a Problem Statement draft =20 =20 Comments welcome =20 Allyn =20 Multi-streams for Telepresence Description of Work =20 =20 =20 Background One branch of video conferencing has evolved that is focused on = immersive "being there" experience. Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were = mainly research projects or business systems with limited deployments. = In recent years telepresence systems have seen considerable market = success. Following the model of early systems, the first wave of = commercial systems have been typically located in specially designed = single-purpose rooms with multiple relatively large displays permitting = life size image reproduction, multiple cameras, encoders, decoders and = microphones. These systems have several important characteristics that = are different from more traditional video conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order = to improve participant nonverbal communication. These systems preserve = essential group meeting characteristics such as eye contact, group = gestures, seating order and spatial audio by carefully orchestrating the = miking and camera angles at each of the sites . This is distinct from = the more traditional approach where the geometric relationship between = media streams is not used to preserve inter-stream communication aspects = such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve = immersion. With telepresence systems, cinematographic aspects of the = local environment reproduction are carefully planned including color, = table shape, seating and lighting so that when combined with large high = quality displays, a strong sense of a "trompe l'oeil" or "being there" = immersive experience is created. Typical video conference systems do = not include these considerations. =20 As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal = communication and immersive values of telepresence via smaller, less = expensive and more flexible video conferencing systems for a variety of = venues, such as individual offices, homes and kiosks. These are also = telepresence systems, since the audio and video quality is high enough = to allow clear image reproduction for nonverbal communication, they are = able to send and receive multiple media streams, and large coordinated = multi image displays are available for immersive installations. As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available. =20 Problem Although telepresence systems are based on open standards such as RTP, = SIP, H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call. A major factor in the inability of Telepresence systems = to work with each other is that there is no standard description of the = multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio = streams sent from remote participants must be understood by receivers so = that they can be presented in a coherent and life-like manner. This = includes the ability to present the remote participants at their true = size for their apparent distance, while maintaining correct eye contact, = gesticular cues, and simultaneously providing a spatial audio sound = stage consistent with the video presentation. The receiving device that = decides how to display the incoming information needs to understand a = number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is = related to each of the displays, etc.=20 =20 Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to = define and specify for SIP-based systems the content of media = multi-stream messages and the way these will be transported.=20 =20 This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference = bridges. It will specify variables that describe the semantics of the = media streams and the recommended behavior to achieve interoperability. = =20 This requires considering current widely deployed use cases, such as = single and multiple screens, multi-point, Scalable Video Coding (SVC), = as well as cases that are expected to be implemented using the protocol = framework produced by this work item. The methodology for describing = the variables must allow extensibility of the variables, since = telepresence is still a young technology and may have use cases that are = not currently considered. =20 The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media = streams, including a specification of variables required to support the = use cases. This work item will consider the reuse of existing IETF = protocols and produce an architecture/protocol framework document = describing the protocols required to be implemented to support this = functionality. The document will identify any enhancements required to = existing protocols as well as describing new protocol(s) for = interoperable multi-streams negotiation that may be required. =20 Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe. =20 Scope The scope includes both systems that provide a fully immersive = experience, and systems that interwork with them and therefore need to = understand the same multiple stream semantics. =20 =20 The focus of this work is on audio and video multiple streams. Other = media types may be considered, however development of methodologies for = them is not within the scope of this work. =20 Interoperation with standards compliant systems is required, such as = SIP-based video conferencing systems. However, backwards compatibility = with existing non-standards compliant telepresence systems is not = required. =20 =20 =20 The group will produce - Requirements and use cases =20 - Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing = protocol enhancements and new protocol functionality required =20 - Specification of a new protocol to support telepresence multi-streams = [if required] =20 Goals and Milestones Nov 2010=20 =20 Use Cases and Requirements to IESG as Informational RFC=20 Nov 2010 March 2011=20 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC=20 March 2011 Revise Charter [IF new protocol is not required] Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 =20 =20 ------_=_NextPart_001_01CB0284.AC864E53 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A comment on the following = sentence in the updated charter:

 

“This requires considering current = widely deployed use cases, such as single and multiple screens, = multi-point, Scalable Video Coding (SVC), as well as cases that are = expected to be implemented using the protocol framework produced by this = work item.=A0 ”

 

Addressing = use cases such as single and multiple screen systems, as well as both = point-to-point and multi-point calling is great. =A0However I do not = understand why a specific video codec or coding technique has been added = to the same context.  The charter shouldn’t recommend or = limit the work for any specific codec (it should be codec = agnostic),  and I suggest the charter should be changed to comply = with this. 

 

-h

 

Fra:<= /b> = dispatch-bounces@ietf.org p=E5 vegne av Allyn Romanow = (allyn)
Sendt: on 02.06.2010 18:11
Til: = dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings = (fluffy)
Emne: [dispatch] Updated charter/work description for = telepresencemulti-streams

Folks,

Here is a version of the work description that addresses = the comments made on the first draft.

The changes include: =

1.       Charter section, qualification that we are working on = SIP-based systems

2.       Charter section, minor word = smithing

3.       Charter section, reference to RAI WG with relevant = work

4.       Scope section, clarification of interoperability = requirements

5.       Scope section, replacement of second paragraph regarding = treatment of non-video non-audio media types

6.       Goals and Milestones – addition of a Problem = Statement draft

 

 

Comments welcome

 

Allyn

 

Multi-streams = for Telepresence Description of Work

 

 

 

Background

One branch of = video conferencing has evolved that is focused on immersive “being = there” experience.  Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were = mainly research projects or business systems with limited = deployments.  In recent years telepresence systems have seen = considerable market success.  Following the model of early systems, = the first wave of commercial systems have been typically located in = specially designed single-purpose rooms with multiple relatively large = displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones.  These systems have several = important characteristics that are different from more traditional video = conferencing systems. 

 

The first = difference concerns controlling the visual viewpoint in order to improve = participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, = seating order and spatial audio by carefully orchestrating the miking = and camera angles at each of the sites . This is distinct from the more = traditional approach where the geometric relationship between media = streams is not used to preserve inter-stream communication aspects such = as eye contact and group dynamics. 

 

A second = difference is manipulation of the environment to improve = immersion.  With telepresence systems, cinematographic aspects of = the local environment reproduction are carefully planned including = color, table shape, seating and lighting so that when combined with = large high quality displays, a strong sense of a "trompe = l'oeil" or "being there" immersive experience is = created.  Typical video conference systems do not include these = considerations.

 

As telepresence video systems = have become successful in the market, manufacturers have started = exploring delivery of the nonverbal communication and immersive values = of telepresence via smaller, less expensive and more flexible video = conferencing systems for a variety of venues, such as individual = offices, homes and kiosks. These are also  telepresence systems, = since the audio and video quality is high enough to allow clear image = reproduction for nonverbal communication, they are able to send and = receive multiple media streams, and large coordinated multi image = displays are available for immersive installations.   As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available.

 

Problem

Although = telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call.  A major factor in the inability of Telepresence = systems to work with each other is that there is no standard description = of the multiple streams that comprise the media flows.

 

For example, in = a multiple screen conference, the video and audio streams sent from = remote participants must be understood by receivers so that they can be = presented in a coherent and life-like manner. This includes the ability = to present the remote participants at their true size for their apparent = distance, while maintaining correct eye contact, gesticular cues, and = simultaneously providing a spatial audio sound stage consistent with the = video presentation.  The receiving device that decides how to = display the incoming information needs to understand a number of = variables such as the spatial position of the speaker, the field of view = of the cameras, the camera zoom, which media stream is related to each = of the displays, etc.

 

Charter

The Telepresence = Multi-Streams work item in DISPATCH is chartered to define and specify = for SIP-based systems the content of media multi-stream messages and the = way these will be transported.

 

This work will = provide a standard for the exchange of media semantic information that = will foster interoperable end stations and conference bridges. It will = specify  variables that describe the semantics of the media streams = and the recommended behavior to achieve interoperability.  =

 

This requires considering = current widely deployed use cases, such as single and multiple screens, = multi-point, Scalable Video Coding (SVC), as well as cases that are = expected to be implemented using the protocol framework produced by this = work item.  The methodology for describing the variables must allow = extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently = considered.

 

The work item will identify = use cases, define requirements, and define a method for describing and = transporting information about multiple media streams, including a = specification of variables required to support the use cases. This work = item will consider the reuse of existing IETF protocols and produce an = architecture/protocol framework document describing the protocols = required to be implemented to support this functionality.  The = document will identify any enhancements required to existing protocols = as well as describing new protocol(s) for interoperable multi-streams = negotiation that may be required.

 

Relevant work to = be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe.

 

Scope

The scope = includes both systems that provide a fully immersive experience, and = systems that interwork with them and therefore need to understand the = same multiple stream semantics.

 

 

The focus of = this work is on audio and video multiple streams.  Other media = types may be considered, however development of methodologies for them = is not within the scope of this work.

 

Interoperation = with standards compliant systems is required, such as SIP-based video = conferencing systems.  However, backwards compatibility with = existing non-standards compliant telepresence systems is not = required.

 

 

 

The group will = produce

- Requirements and use = cases

 

- Architectural Framework = describing the protocols required to be implemented to support this = functionality and identifying existing protocol enhancements and new = protocol functionality required

 

- Specification = of a new protocol to support telepresence multi-streams [if = required]

 

Goals and = Milestones

Nov = 2010

 

Use Cases and Requirements to = IESG as Informational RFC

Nov = 2010

March 2011 =

Problem Statement to IESG as = Informational RFC

Architecture to IESG as = Informational RFC

March = 2011

Revise Charter [IF new = protocol is not required]

Nov = 2011

Submit protocol draft to IESG = as Proposed Standard RFC

 

 

 

------_=_NextPart_001_01CB0284.AC864E53-- From jf.mule@cablelabs.com Wed Jun 2 14:00:12 2010 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 6FC743A6A4D for ; Wed, 2 Jun 2010 14:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.137 X-Spam-Level: ** X-Spam-Status: No, score=2.137 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vzhmy6lUyQOA for ; Wed, 2 Jun 2010 14:00:11 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 64C0F3A6A5D for ; Wed, 2 Jun 2010 14:00:11 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o52Kxv0h029168; Wed, 2 Jun 2010 14:59:57 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 2 Jun 2010 14:59:57 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 2 Jun 2010 14:59:57 -0600 From: Jean-Francois Mule To: Cullen Jennings , DISPATCH list Date: Wed, 2 Jun 2010 14:59:53 -0600 Thread-Topic: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) Thread-Index: AcsBqzls6RlPA8uQRtSKkuynVEiRUgA54+Fg Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB49@srvxchg> 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-Approved: ondar Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 21:00:12 -0000 Hi, I support this proposed work to be taken by IETF under a new working gro= up. There are certainly concrete deliverables that would merit IETF consen= sus to spur multi-vendor interoperability. A few comments below, mostly to help bash the proposed charter. Jean-Francois. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On Behalf Of Cullen Jennings > Sent: Tuesday, June 01, 2010 10:55 AM > To: DISPATCH list > Subject: [dispatch] Charter Proposal: Verification Involving PSTN > Reachability (VIPR) >=20 >=20 > I've been talking to a lot of people about the VIPR drafts - here > is a first cut of a proposal for a WG that could do this. I'm sure > the charter proposal needs a bunch of work but I wanted to get the > discussion rolling on the list. >=20 > Thanks, Cullen >=20 > (PS - this is sent in my individual contributor role. Take all my > posts about VIPR to be in my individual role not my co-chair role) >=20 > ------------------------------------------------------- >=20 > ViPR Charter Proposal (Version 0) >=20 > WG Name: Verification Involving PSTN Reachability (VIPR) >=20 > There are two globally deployed address spaces for communications > that more than a billion people use on a daily basis. They are > phone numbers and DNS rooted address such as web servers and email > addresses. The federation design of SIP is primarily designed for ^^^^^^^^^^^^^^^^^^^^^^^^ Given some folks talk about SIP federations in the context of speermint (ht= tp://tools.ietf.org/html/rfc5486#section-5) and I don't think this is what = you mean here, this choice of terms may not be the best. As much as some f= olks disagree on the worthiness of the output of speermint, at least SIP fe= derations are described there. Would recommend clarifying this somehow. =20 > email style addresses yet a large percentage of SIP deployments > primarily use phone numbers for identifying users. The goal of this > working group is to allows people to use SIP to federate over the ^^^^^^^^^^^^^^^^^^^ my understanding is that those people would not only use SIP but some other= smarts to put some stuff in DHTs to enable PSTN reachability verification.= This implies that the solution solely relies on SIP. May want to expand o= r clarify, or else qualify the sentence further. > the internet while still using phone numbers to identify the person > they wish to communicate with. >=20 > The VIPR WG will address this problem by developing a peer to peer > based approach to finding SIP domains that claim to be responsible ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That may open a rathole: what does it mean to be responsible for a given ph= one number (worst case, Rich Shockey will chime in and will muddy this more= , or John Elwell will claim this should have been in speermint but it canno= t be found there...). Do you mean any SIP Service Provider (http://tools.ietf.org/html/rfc5486#se= ction-3.9) on the signaling path of a SIP invite or dialog-initiating reque= st for that telephone number? Do you mean the SIP domain responsible for t= he last hop before the SIP UA? Both? Or is it the latter with the pre-requ= isite that PSTN connectivity is required somehow? > for a given phone number and the WG will design validation > protocols to ensure a reasonable likelihood that a given domain > actually is responsible for the phone number. One initial > validation protocol will be based on a domain being able to prove > it received a particular phone call over the PSTN based on both > sides knowing the start and stop times of that call. Other This last sentence is advocating one specific solution. =20 I think the VIPR drafts are powerful and this may be part of a working solu= tion. But at this stage in the WG charter definition, would it be preferab= le to say something like: Some validation protocols may be based on additional knowledge gathered ar= ound a SIP call, for example, the ability to prove a call was received over= the PSTN based on start and stop times. It leave things open and welcomes other proposals. It also does not preclu= de the validation protocol you have documented. > validation schemes, such as examining fingerprints or watermarking > of PSTN media, to show that a domain received a particular PSTN > phone call may be considered by the working group.=20 These are additional examples that must be part of the same bucket as the o= ne before imo. Currently it reads that PSTN+start+stop is the initial one,= others may be considered later. =20 I have no preference and like the elegance of the approach in some the VIPR= drafts. But the charter should make clear that the WG will decide this. > To help mitigate > SPAM over SIP issues, the WG will define an token based > authorization scheme so that domain using SIP to federate can > choose to check that incoming SIP calls are from a domain that > successfully validated a phone number. Same here, you state a solution to a pb. I would prefer to have a requirem= ent in the charter that mandates the WG comes up with a method to help miti= gate SPIT by ensuring that a domain using SIP can validate incoming calls a= re indeed from a domain that successfully validated the TN. > The problem statement and some possible starting points for > solutions are further desired in the following internet drafts > which shall form the bases of the WG documents: > draft-rosenberg-dispatch-vipr-overview > draft-rosenberg-dispatch-vipr-reload-usage > draft-rosenberg-dispatch-vipr-pvp > draft-rosenberg-dispatch-vipr-sip-antispam >=20 > The working group will carefully coordinate with the security area, > O&M area, as well as the appropriate RAI WG including sipcore and > p2psip. >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jf.mule@cablelabs.com Wed Jun 2 14:02:16 2010 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 0F2CF3A6A65 for ; Wed, 2 Jun 2010 14:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.582 X-Spam-Level: * X-Spam-Status: No, score=1.582 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F2JHoTWwO4v for ; Wed, 2 Jun 2010 14:02:15 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 48C943A6A4F for ; Wed, 2 Jun 2010 14:02:15 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o52L201T029377; Wed, 2 Jun 2010 15:02:00 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 2 Jun 2010 15:02:00 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 2 Jun 2010 15:02:00 -0600 From: Jean-Francois Mule To: Peter Musgrave Date: Wed, 2 Jun 2010 15:01:57 -0600 Thread-Topic: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) Thread-Index: AcsBuF4M4AlnfqVZS6GMjZhlxb48/wA3kqIg Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB4B@srvxchg> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 21:02:16 -0000 Peter Musgrave wrote: > Does the charter need to say anything explicitly about not relying > on > any of the work which uses ENUMs in DNS as a way of associating SIP > endpoints and IP addresses? I don't think the charter should exclude anything that may be used in some = context as validation schemes. =20 Jean-Fran=E7ois From peter.musgrave@magorcorp.com Wed Jun 2 14:02:43 2010 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 058073A6A6A for ; Wed, 2 Jun 2010 14:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqVKpiGBpX6t for ; Wed, 2 Jun 2010 14:02:42 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by core3.amsl.com (Postfix) with ESMTP id 3B4073A6A65 for ; Wed, 2 Jun 2010 14:02:42 -0700 (PDT) Received: by ywh12 with SMTP id 12so6815730ywh.19 for ; Wed, 02 Jun 2010 14:02:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.166.5 with SMTP id o5mr8550630ybe.404.1275512546799; Wed, 02 Jun 2010 14:02:26 -0700 (PDT) Received: by 10.150.199.12 with HTTP; Wed, 2 Jun 2010 14:02:26 -0700 (PDT) In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB49@srvxchg> References: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB49@srvxchg> Date: Wed, 2 Jun 2010 17:02:26 -0400 Message-ID: From: Peter Musgrave To: Jean-Francois Mule Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 21:02:43 -0000 >Hi, > > I support this proposed work to be taken by IETF under a new working group. There are certainly concrete deliverables that would merit IETF consensus to spur multi-vendor >interoperability. +1 From jf.mule@cablelabs.com Wed Jun 2 14:04:42 2010 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 A41183A6A4F for ; Wed, 2 Jun 2010 14:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.859 X-Spam-Level: * X-Spam-Status: No, score=1.859 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1odThUnAdo45 for ; Wed, 2 Jun 2010 14:04:42 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id E13F43A68DC for ; Wed, 2 Jun 2010 14:04:41 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o52L4QfV029575; Wed, 2 Jun 2010 15:04:26 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 2 Jun 2010 15:04:26 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 2 Jun 2010 15:04:26 -0600 From: Jean-Francois Mule To: Paul Kyzivat , Peter Musgrave Date: Wed, 2 Jun 2010 15:04:23 -0600 Thread-Topic: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) Thread-Index: AcsBveYwTAuoK44jQnyQUMfX/HMNTAA2PwiA Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB50@srvxchg> References: <4C055AC7.1080308@cisco.com> In-Reply-To: <4C055AC7.1080308@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 21:04:42 -0000 Paul wrote: > As I understand it, the new WG is about coming up with technique(s) > that > work and are deployable in the real world. While in principle > public > ENUM could be used for this, in practice it isn't deployed and so > isn't > really usable.=20 To Patrick's point on the ENUM WG list on 5/19, it depends what you mean by= ENUM here. There are probably a lot of SIP calls routed in networks today (and SMS-MMS= ) that use some kind of ENUM protocol implementations. Jean-Fran=E7ois From pkyzivat@cisco.com Wed Jun 2 14:15:09 2010 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 5D59A3A6A82 for ; Wed, 2 Jun 2010 14:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.596 X-Spam-Level: X-Spam-Status: No, score=-8.596 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06mAcee6Ler7 for ; Wed, 2 Jun 2010 14:15:03 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1AB533A6A7B for ; Wed, 2 Jun 2010 14:15:00 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIFmBkxAaHte/2dsb2JhbACeI3GnMZojhRYE X-IronPort-AV: E=Sophos;i="4.53,348,1272844800"; d="scan'208";a="138399562" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 02 Jun 2010 21:14:46 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o52LEijp005292; Wed, 2 Jun 2010 21:14:44 GMT Message-ID: <4C06C9C8.9020203@cisco.com> Date: Wed, 02 Jun 2010 17:14:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jean-Francois Mule References: <4C055AC7.1080308@cisco.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FAB50@srvxchg> In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB50@srvxchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 21:15:09 -0000 Jean-Francois Mule wrote: > Paul wrote: >> As I understand it, the new WG is about coming up with technique(s) >> that >> work and are deployable in the real world. While in principle >> public >> ENUM could be used for this, in practice it isn't deployed and so >> isn't >> really usable. > > To Patrick's point on the ENUM WG list on 5/19, it depends what you mean by ENUM here. > There are probably a lot of SIP calls routed in networks today (and SMS-MMS) that use some kind of ENUM protocol implementations. I did explicitly say *public* ENUM. I realize other variants of ENUM are in use, but they aren't relevant to *this* problem statement, and I think what I said is true for *public* ENUM. Its possible that this could result in a grab bag of techniques. Potentially public ENUM could be tried, and used if there is a workable entry, while some of the more complex techniques could be tried if there is no workable entry in public ENUM. Thanks, Paul From dworley@avaya.com Wed Jun 2 14:21:55 2010 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 14E233A68F0 for ; Wed, 2 Jun 2010 14:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.617 X-Spam-Level: X-Spam-Status: No, score=-0.617 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MS2RgKCRCmVe for ; Wed, 2 Jun 2010 14:21:54 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id DEA243A67FB for ; Wed, 2 Jun 2010 14:21:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,348,1272859200"; d="scan'208";a="221128078" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Jun 2010 17:21:40 -0400 X-IronPort-AV: E=Sophos;i="4.53,348,1272859200"; d="scan'208";a="480391805" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Jun 2010 17:21:40 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 2 Jun 2010 17:21:40 -0400 From: "WORLEY, Dale R (Dale)" To: Cullen Jennings , DISPATCH list Date: Wed, 2 Jun 2010 17:20:25 -0400 Thread-Topic: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) Thread-Index: AcsBqzrFyHd4No72Q/iGb4t2HVczUgA7i/sq 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 Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 21:21:55 -0000 I've improved the wording in various places and carefully removed any presu= mptions regarding the specific solution to be delivered: ViPR Charter Proposal (a revision) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications that more than a billion people use on a daily basis: E.164 phone numbers and DNS-rooted address (such as web servers and email addresses). The federation design of SIP is primarily designed for email-style addresses, yet a large percentage of SIP deployments primarily use phone numbers for identifying users. The goal of this working group is to allow people to use SIP to federate over the the Internet while still using phone numbers to identify the person they wish to communicate with. The VIPR WG will address this problem by developing one or more peer-to-peer based approaches to determining and validating the SIP URI(s) that are equivalent to a given phone number, without requiring reference to a global, accurate database. One approach to be considered will be based on a domain being able to prove it received a particular phone call over the PSTN, based on both sides knowing the start and stop times of that call. This approach is described in: draft-rosenberg-dispatch-vipr-overview draft-rosenberg-dispatch-vipr-reload-usage draft-rosenberg-dispatch-vipr-pvp draft-rosenberg-dispatch-vipr-sip-antispam Other validation techniques (such as examining fingerprints or watermarking of PSTN media) may be considered by the working group. To help mitigate SPAM over SIP issues, the WG also define one or more authorization schemes allowing a recipient to verify that an incoming SIP call is from a source that has previously executed a validation protocol with the recipient. The working group will carefully coordinate with the security area, O&M area, and the appropriate RAI WGs (including sipcore and p2psip). Dale From jf.mule@cablelabs.com Wed Jun 2 15:25:31 2010 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 0432428C139 for ; Wed, 2 Jun 2010 15:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.952 X-Spam-Level: * X-Spam-Status: No, score=1.952 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRi-8ZPPSZpE for ; Wed, 2 Jun 2010 15:25:30 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 39A2728C0E8 for ; Wed, 2 Jun 2010 15:25:30 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o52MPG5H002931; Wed, 2 Jun 2010 16:25:16 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 2 Jun 2010 16:25:16 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 2 Jun 2010 16:25:16 -0600 From: Jean-Francois Mule To: Paul Kyzivat Date: Wed, 2 Jun 2010 16:25:13 -0600 Thread-Topic: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) Thread-Index: AcsCmKKwgc0LdzlqSDCSQ82nqgqu9AACYWqQ Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB65@srvxchg> References: <4C055AC7.1080308@cisco.com> <76AC5FEF83F1E64491446437EA81A61F7CF49FAB50@srvxchg> <4C06C9C8.9020203@cisco.com> In-Reply-To: <4C06C9C8.9020203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 02 Jun 2010 22:25:31 -0000 > Jean-Francois Mule wrote: > > Paul wrote: > >> As I understand it, the new WG is about coming up with > technique(s) > >> that > >> work and are deployable in the real world. While in principle > >> public > >> ENUM could be used for this, in practice it isn't deployed and > so > >> isn't > >> really usable. > > > > To Patrick's point on the ENUM WG list on 5/19, it depends what > you mean by ENUM here. > > There are probably a lot of SIP calls routed in networks today > (and SMS-MMS) that use some kind of ENUM protocol implementations. >=20 > I did explicitly say *public* ENUM. You're right. > I realize other variants of ENUM are in use, but they aren't > relevant to > *this* problem statement, and I think what I said is true for > *public* ENUM. > Its possible that this could result in a grab bag of techniques. > Potentially public ENUM could be tried, and used if there is a > workable > entry, while some of the more complex techniques could be tried if > there > is no workable entry in public ENUM. Yes. From alex@vidyo.com Wed Jun 2 16:21:20 2010 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 100FD3A6A25 for ; Wed, 2 Jun 2010 16:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 lYPnJ+NstWqv for ; Wed, 2 Jun 2010 16:21:10 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 128963A6926 for ; Wed, 2 Jun 2010 16:20:57 -0700 (PDT) Received: from BH015.mail.lan ([10.110.21.115]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 19:20:45 -0400 Received: from HUB015.mail.lan ([10.110.17.15]) by BH015.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 19:20:44 -0400 Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 2 Jun 2010 19:20:39 -0400 From: Alex Eleftheriadis To: =?Windows-1252?Q?H=E5kon_Dahle?= Date: Wed, 2 Jun 2010 19:20:39 -0400 Thread-Topic: [dispatch] Updated charter/work description for telepresence multi-streams Thread-Index: AcsCqjjSwfLIbUWBQA+HnPLCAE5x3w== Message-ID: References: <9F6ACAE02B6DD040A1E259977622CFDB086D58B3@oslexcp1.eu.tandberg.int> In-Reply-To: <9F6ACAE02B6DD040A1E259977622CFDB086D58B3@oslexcp1.eu.tandberg.int> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8B9CF05B89B4946A14AA1F6FABDAE4Cvidyocom_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Jun 2010 23:20:44.0539 (UTC) FILETIME=[39AAECB0:01CB02AA] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated charter/work description for telepresence multi-streams 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, 02 Jun 2010 23:21:20 -0000 --_000_C8B9CF05B89B4946A14AA1F6FABDAE4Cvidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Inline. On Jun 2, 2010, at 9:51 PM, H=E5kon Dahle wrote: A comment on the following sentence in the updated charter: =93This requires considering current widely deployed use cases, such as sin= gle and multiple screens, multi-point, Scalable Video Coding (SVC), as well= as cases that are expected to be implemented using the protocol framework = produced by this work item. =94 Addressing use cases such as single and multiple screen systems, as well as= both point-to-point and multi-point calling is great. However I do not un= derstand why a specific video codec or coding technique has been added to t= he same context. The charter shouldn=92t recommend or limit the work for a= ny specific codec (it should be codec agnostic), and I suggest the charter= should be changed to comply with this. Right. I believe that the correct reference is to alternative architectures= for the server in both point-to-point and multi-point calls, where scalabi= lity (which includes simulcasting, pyramidal coding such as SVC, and multip= le description coding) lends itself to VRUs (Video Routing Units) as oppose= d to MCUs. The VRU employs a "subscribe" model, made possible by scalabilit= y, and which works quite differently than an MCU. --Alex -h ________________________________ Fra: dispatch-bounces@ietf.org p=E5 vegne= av Allyn Romanow (allyn) Sendt: on 02.06.2010 18:11 Til: dispatch@ietf.org; mary.ietf.barnes@gmail.co= m; Cullen Jennings (fluffy) Emne: [dispatch] Updated charter/work description for telepresencemulti-str= eams Folks, Here is a version of the work description that addresses the comments made = on the first draft. The changes include: 1. Charter section, qualification that we are working on SIP-based sy= stems 2. Charter section, minor word smithing 3. Charter section, reference to RAI WG with relevant work 4. Scope section, clarification of interoperability requirements 5. Scope section, replacement of second paragraph regarding treatment= of non-video non-audio media types 6. Goals and Milestones =96 addition of a Problem Statement draft Comments welcome Allyn Multi-streams for Telepresence Description of Work Background One branch of video conferencing has evolved that is focused on immersive = =93being there=94 experience. Referred to in various ways such as virtual = conferencing, telepresence or media spaces, early systems were mainly resea= rch projects or business systems with limited deployments. In recent years= telepresence systems have seen considerable market success. Following the= model of early systems, the first wave of commercial systems have been typ= ically located in specially designed single-purpose rooms with multiple rel= atively large displays permitting life size image reproduction, multiple ca= meras, encoders, decoders and microphones. These systems have several impo= rtant characteristics that are different from more traditional video confer= encing systems. The first difference concerns controlling the visual viewpoint in order to = improve participant nonverbal communication. These systems preserve essenti= al group meeting characteristics such as eye contact, group gestures, seati= ng order and spatial audio by carefully orchestrating the miking and camera= angles at each of the sites . This is distinct from the more traditional a= pproach where the geometric relationship between media streams is not used = to preserve inter-stream communication aspects such as eye contact and grou= p dynamics. A second difference is manipulation of the environment to improve immersion= . With telepresence systems, cinematographic aspects of the local environm= ent reproduction are carefully planned including color, table shape, seatin= g and lighting so that when combined with large high quality displays, a st= rong sense of a "trompe l'oeil" or "being there" immersive experience is cr= eated. Typical video conference systems do not include these consideration= s. As telepresence video systems have become successful in the market, manufac= turers have started exploring delivery of the nonverbal communication and i= mmersive values of telepresence via smaller, less expensive and more flexib= le video conferencing systems for a variety of venues, such as individual o= ffices, homes and kiosks. These are also telepresence systems, since the a= udio and video quality is high enough to allow clear image reproduction for= nonverbal communication, they are able to send and receive multiple media = streams, and large coordinated multi image displays are available for immer= sive installations. As the industry develops, the line between telepresen= ce and video conferencing may become blurred as nonverbal communication and= immersive installations become broadly available. Problem Although telepresence systems are based on open standards such as RTP, SIP,= H.264, H.323 suite, they cannot easily interoperate with each other withou= t operator assistance and expensive additional equipment that translates fr= om one vendor to another. It would be like having to make sure all parties = are on the same equipment (and network) when making a telephone call. A ma= jor factor in the inability of Telepresence systems to work with each other= is that there is no standard description of the multiple streams that comp= rise the media flows. For example, in a multiple screen conference, the video and audio streams s= ent from remote participants must be understood by receivers so that they c= an be presented in a coherent and life-like manner. This includes the abili= ty to present the remote participants at their true size for their apparent= distance, while maintaining correct eye contact, gesticular cues, and simu= ltaneously providing a spatial audio sound stage consistent with the video = presentation. The receiving device that decides how to display the incomin= g information needs to understand a number of variables such as the spatial= position of the speaker, the field of view of the cameras, the camera zoom= , which media stream is related to each of the displays, etc. Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define= and specify for SIP-based systems the content of media multi-stream messag= es and the way these will be transported. This work will provide a standard for the exchange of media semantic inform= ation that will foster interoperable end stations and conference bridges. I= t will specify variables that describe the semantics of the media streams = and the recommended behavior to achieve interoperability. This requires considering current widely deployed use cases, such as single= and multiple screens, multi-point, Scalable Video Coding (SVC), as well as= cases that are expected to be implemented using the protocol framework pro= duced by this work item. The methodology for describing the variables must= allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently considered. The work item will identify use cases, define requirements, and define a me= thod for describing and transporting information about multiple media strea= ms, including a specification of variables required to support the use case= s. This work item will consider the reuse of existing IETF protocols and pr= oduce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality. The document wil= l identify any enhancements required to existing protocols as well as descr= ibing new protocol(s) for interoperable multi-streams negotiation that may = be required. Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and FECf= rame. Scope The scope includes both systems that provide a fully immersive experience, = and systems that interwork with them and therefore need to understand the s= ame multiple stream semantics. The focus of this work is on audio and video multiple streams. Other media= types may be considered, however development of methodologies for them is = not within the scope of this work. Interoperation with standards compliant systems is required, such as SIP-ba= sed video conferencing systems. However, backwards compatibility with exis= ting non-standards compliant telepresence systems is not required. The group will produce - Requirements and use cases - Architectural Framework describing the protocols required to be implement= ed to support this functionality and identifying existing protocol enhancem= ents and new protocol functionality required - Specification of a new protocol to support telepresence multi-streams [if= required] Goals and Milestones Nov 2010 Use Cases and Requirements to IESG as Informational RFC Nov 2010 March 2011 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC March 2011 Revise Charter [IF new protocol is not required] Nov 2011 Submit protocol draft to IESG as Proposed Standard RFC _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C8B9CF05B89B4946A14AA1F6FABDAE4Cvidyocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Inline. 

On Jun 2, 2010, at 9:51 PM, H=E5kon Dahle = wrote:

A comment on the following sentence = in the updated charter:
 
=93This requires considering current widely deployed use c= ases, such as single and multiple screens, multi-point, Scalable Video Codi= ng (SVC), as well as cases that are expected to be implemented using the pr= otocol framework produced by this work item.  =94
<= span lang=3D"EN-US" style=3D"font-size: 12pt; "> 
<= span lang=3D"EN-US" style=3D"color: rgb(31, 73, 125); ">Addressing use case= s such as single and multiple screen systems, as well as both point-to-poin= t and multi-point calling is great.  However I do not understand why a= specific video codec or coding technique has been added to the same contex= t.  The charter shouldn=92t recommend or limit the work for any specif= ic codec (it should be codec agnostic),  and I suggest the charter sho= uld be changed to comply with this. 

Right. I believe that the= correct reference is to alternative architectures for the server in both p= oint-to-point and multi-point calls, where scalability (which includes simu= lcasting, pyramidal coding such as SVC, and multiple description coding) le= nds itself to VRUs (Video Routing Units) as opposed to MCUs. The VRU employ= s a "subscribe" model, made possible by scalability, and which works quite = differently than an MCU. 

--Alex

<= div class=3D"WordSection1">
 
-h
 

Fra: dispatch-bounces@ietf.org p=E5 vegne av Allyn Romano= w (allyn)
Sendt: on 02.06.2010 18:11
Til:&= nbsp;dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings (fluffy)
Emne: [dispatch] Updated charter/work description for telepre= sencemulti-streams

<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-bottom: 0.0001pt; m= argin-left: 0cm; font-size: 11pt; font-family: Calibri, sans-serif; text-al= ign: center; ">Multi-streams for Telepresence Description of Work
The first difference concerns controlling the visual viewpoint in or= der to improve participant nonverbal communication. These systems preserve = essential group meeting characteristics such as eye contact, group gestures= , seating order and spatial audio by carefully orchestrating the miking and= camera angles at each of the sites . This is distinct from the more tradit= ional approach where the geometric relationship between media streams is no= t used to preserve inter-stream communication aspects such as eye contact a= nd group dynamics. 
 
A second difference is manipulation of the= environment to improve immersion.  With telepresence systems, cinemat= ographic aspects of the local environment reproduction are carefully planne= d including color, table shape, seating and lighting so that when combined = with large high quality displays, a strong sense of a "trompe l'oeil" or "b= eing there" immersive experience is created.  Typical video conference= systems do not include these considerations.
 
As telepresence video= systems have become successful in the market, manufacturers have started e= xploring delivery of the nonverbal communication and immersive values of te= lepresence via smaller, less expensive and more flexible video conferencing= systems for a variety of venues, such as individual offices, homes and kio= sks. These are also  telepresence systems, since the audio and video q= uality is high enough to allow clear image reproduction for nonverbal commu= nication, they are able to send and receive multiple media streams, and lar= ge coordinated multi image displays are available for immersive installatio= ns.   As the industry develops, the line between telepresence and= video conferencing may become blurred as nonverbal communication and immer= sive installations become broadly available.
 
Problem<= span lang=3D"EN-US">
Although telepresence systems are based on ope= n standards such as RTP, SIP, H.264, H.323 suite, they cannot easily intero= perate with each other without operator assistance and expensive additional= equipment that translates from one vendor to another. It would be like hav= ing to make sure all parties are on the same equipment (and network) when m= aking a telephone call.  A major factor in the inability of Telepresen= ce systems to work with each other is that there is no standard description= of the multiple streams that comprise the media flows.
 
= For example= , in a multiple screen conference, the video and audio streams sent from re= mote participants must be understood by receivers so that they can be prese= nted in a coherent and life-like manner. This includes the ability to prese= nt the remote participants at their true size for their apparent distance, = while maintaining correct eye contact, gesticular cues, and simultaneously = providing a spatial audio sound stage consistent with the video presentatio= n.  The receiving device that decides how to display the incoming info= rmation needs to understand a number of variables such as the spatial posit= ion of the speaker, the field of view of the cameras, the camera zoom, whic= h media stream is related to each of the displays, etc.
 
= Charter<= /span>
The Telepresence Multi-Streams work= item in DISPATCH is chartered to define and specify for SIP-based systems = the content of media multi-stream messages and the way these will be transp= orted.
=  
This work will provide a standard for the exchange of media = semantic information that will foster interoperable end stations and confer= ence bridges. It will specify  variables that describe the semantics o= f the media streams and the recommended behavior to achieve interoperabilit= y. 
 
This requires considering current widely deployed use case= s, such as single and multiple screens, multi-point, Scalable Video Coding = (SVC), as well as cases that are expected to be implemented using the proto= col framework produced by this work item.  The methodology for describ= ing the variables must allow extensibility of the variables, since telepres= ence is still a young technology and may have use cases that are not curren= tly considered.
 
The work item will identify use cases, define req= uirements, and define a method for describing and transporting information = about multiple media streams, including a specification of variables requir= ed to support the use cases. This work item will consider the reuse of exis= ting IETF protocols and produce an architecture/protocol framework document= describing the protocols required to be implemented to support this functi= onality.  The document will identify any enhancements required to exis= ting protocols as well as describing new protocol(s) for interoperable mult= i-streams negotiation that may be required.
 
Relevant work to be d= rawn upon has been done in XCON, MMUSIC, AVT, and FECframe.
 
Scop= e
The scope includes both systems t= hat provide a fully immersive experience, and systems that interwork with t= hem and therefore need to understand the same multiple stream semantics.
 
 
The focus of t= his work is on audio and video multiple streams.  Other media types ma= y be considered, however development of methodologies for them is not withi= n the scope of this work.
 
Interoperation with standards compliant s= ystems is required, such as SIP-based video conferencing systems.  How= ever, backwards compatibility with existing non-standards compliant telepre= sence systems is not required.
 
&nbs= p;
 
The group will= produce
- Requirements and use ca= ses
&nb= sp;
- Architectural Framework describing the protocols required to = be implemented to support this functionality and identifying existing proto= col enhancements and new protocol functionality required
 
- Specif= ication of a new protocol to support telepresence multi-streams [if require= d]
&nbs= p;
Goals and Milestones
Nov 2010
March 2011
Nov 2010
 
Use Cases and Require= ments to IESG as Informational RFC
Problem Statement to IESG as Informational RFC=
Architecture = to IESG as Informational RFC
March 2011
Revise Charter [IF new protocol is not required]
= Nov 2011=
Submit protocol draft to IESG as = Proposed Standard RFC
 
 
 
_= ______________________________________________
dispatch mailing list
= dispatch@ietf.org
= https://www.ietf.org/mailman/listinfo/dispatch

= --_000_C8B9CF05B89B4946A14AA1F6FABDAE4Cvidyocom_-- From hakon.dahle@tandberg.com Wed Jun 2 17:01:51 2010 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 45F353A691B for ; Wed, 2 Jun 2010 17:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_50=0.001, MIME_8BIT_HEADER=0.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 MI5NOovfcWLu for ; Wed, 2 Jun 2010 17:01:49 -0700 (PDT) Received: from mail178.messagelabs.com (mail178.messagelabs.com [85.158.139.19]) by core3.amsl.com (Postfix) with SMTP id 0B5E33A6926 for ; Wed, 2 Jun 2010 17:01:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: hakon.dahle@tandberg.com X-Msg-Ref: server-3.tower-178.messagelabs.com!1275523295!39569274!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 10693 invoked from network); 3 Jun 2010 00:01:35 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-3.tower-178.messagelabs.com with SMTP; 3 Jun 2010 00:01:35 -0000 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jun 2010 02:01:35 +0200 Received: from 10.47.136.43 ([10.47.136.43]) by oslexcp1.eu.tandberg.int ([10.47.136.29]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Jun 2010 00:01:34 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 thread-topic: [dispatch] Updated charter/work description for telepresencemulti-streams thread-index: AcsCqjjSwfLIbUWBQA+HnPLCAE5x3wABbUvD Message-ID: <7326301cb02af$ee00b17b$2b882f0a@eu.tandberg.int> From: =?utf-8?B?SMOla29uIERhaGxl?= To: Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2010 00:01:35.0230 (UTC) FILETIME=[EE64B1E0:01CB02AF] Date: 3 Jun 2010 02:01:35 +0200 Subject: Re: [dispatch] Updated charter/work description for telepresencemulti-streams 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, 03 Jun 2010 00:01:51 -0000 Agree with Alex to a large extent in that scalability, simulcast, = publish/subscribe may all be applicable to the problem at hand.=0A= =0A= However I do not think the Charter should jump to conclusions on what = happens inside "the server" that Alex is referring to in his email - at = this point I suggest leaving these details out of the charter, to make = sure all options can be investigated.=0A= =0A= -h=0A= =0A= =0A= =0A= ----- Reply message -----=0A= From: "Alex Eleftheriadis" =0A= Date: Wed, Jun 2, 2010 16:20=0A= Subject: [dispatch] Updated charter/work description for = telepresencemulti-streams=0A= To: "H=C3=A5kon Dahle" =0A= Cc: "dispatch@ietf.org" =0A= Inline. On Jun 2, 2010, at 9:51 PM, H=C3=A5kon Dahle wrote: A comment on the following sentence in the updated charter: =E2=80=9CThis requires considering current widely deployed use cases, = such as single and multiple screens, multi-point, Scalable Video Coding = (SVC), as well as cases that are expected to be implemented using the = protocol framework produced by this work item. =E2=80=9D Addressing use cases such as single and multiple screen systems, as well = as both point-to-point and multi-point calling is great. However I do = not understand why a specific video codec or coding technique has been = added to the same context. The charter shouldn=E2=80=99t recommend or = limit the work for any specific codec (it should be codec agnostic), = and I suggest the charter should be changed to comply with this. Right. I believe that the correct reference is to alternative = architectures for the server in both point-to-point and multi-point = calls, where scalability (which includes simulcasting, pyramidal coding = such as SVC, and multiple description coding) lends itself to VRUs = (Video Routing Units) as opposed to MCUs. The VRU employs a "subscribe" = model, made possible by scalability, and which works quite differently = than an MCU. --Alex -h ________________________________ Fra: dispatch-bounces@ietf.org p=C3=A5 = vegne av Allyn Romanow (allyn) Sendt: on 02.06.2010 18:11 Til: dispatch@ietf.org; = mary.ietf.barnes@gmail.com; Cullen = Jennings (fluffy) Emne: [dispatch] Updated charter/work description for = telepresencemulti-streams Folks, Here is a version of the work description that addresses the comments = made on the first draft. The changes include: 1. Charter section, qualification that we are working on SIP-based = systems 2. Charter section, minor word smithing 3. Charter section, reference to RAI WG with relevant work 4. Scope section, clarification of interoperability requirements 5. Scope section, replacement of second paragraph regarding = treatment of non-video non-audio media types 6. Goals and Milestones =E2=80=93 addition of a Problem Statement = draft Comments welcome Allyn Multi-streams for Telepresence Description of Work Background One branch of video conferencing has evolved that is focused on = immersive =E2=80=9Cbeing there=E2=80=9D experience. Referred to in = various ways such as virtual conferencing, telepresence or media spaces, = early systems were mainly research projects or business systems with = limited deployments. In recent years telepresence systems have seen = considerable market success. Following the model of early systems, the = first wave of commercial systems have been typically located in = specially designed single-purpose rooms with multiple relatively large = displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones. These systems have several = important characteristics that are different from more traditional video = conferencing systems. The first difference concerns controlling the visual viewpoint in order = to improve participant nonverbal communication. These systems preserve = essential group meeting characteristics such as eye contact, group = gestures, seating order and spatial audio by carefully orchestrating the = miking and camera angles at each of the sites . This is distinct from = the more traditional approach where the geometric relationship between = media streams is not used to preserve inter-stream communication aspects = such as eye contact and group dynamics. A second difference is manipulation of the environment to improve = immersion. With telepresence systems, cinematographic aspects of the = local environment reproduction are carefully planned including color, = table shape, seating and lighting so that when combined with large high = quality displays, a strong sense of a "trompe l'oeil" or "being there" = immersive experience is created. Typical video conference systems do = not include these considerations. As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal = communication and immersive values of telepresence via smaller, less = expensive and more flexible video conferencing systems for a variety of = venues, such as individual offices, homes and kiosks. These are also = telepresence systems, since the audio and video quality is high enough = to allow clear image reproduction for nonverbal communication, they are = able to send and receive multiple media streams, and large coordinated = multi image displays are available for immersive installations. As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available. Problem Although telepresence systems are based on open standards such as RTP, = SIP, H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call. A major factor in the inability of Telepresence systems = to work with each other is that there is no standard description of the = multiple streams that comprise the media flows. For example, in a multiple screen conference, the video and audio = streams sent from remote participants must be understood by receivers so = that they can be presented in a coherent and life-like manner. This = includes the ability to present the remote participants at their true = size for their apparent distance, while maintaining correct eye contact, = gesticular cues, and simultaneously providing a spatial audio sound = stage consistent with the video presentation. The receiving device that = decides how to display the incoming information needs to understand a = number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is = related to each of the displays, etc. Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to = define and specify for SIP-based systems the content of media = multi-stream messages and the way these will be transported. This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference = bridges. It will specify variables that describe the semantics of the = media streams and the recommended behavior to achieve interoperability. This requires considering current widely deployed use cases, such as = single and multiple screens, multi-point, Scalable Video Coding (SVC), = as well as cases that are expected to be implemented using the protocol = framework produced by this work item. The methodology for describing = the variables must allow extensibility of the variables, since = telepresence is still a young technology and may have use cases that are = not currently considered. The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media = streams, including a specification of variables required to support the = use cases. This work item will consider the reuse of existing IETF = protocols and produce an architecture/protocol framework document = describing the protocols required to be implemented to support this = functionality. The document will identify any enhancements required to = existing protocols as well as describing new protocol(s) for = interoperable multi-streams negotiation that may be required. Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe. Scope The scope includes both systems that provide a fully immersive = experience, and systems that interwork with them and therefore need to = understand the same multiple stream semantics. The focus of this work is on audio and video multiple streams. Other = media types may be considered, however development of methodologies for = them is not within the scope of this work. Interoperation with standards compliant systems is required, such as = SIP-based video conferencing systems. However, backwards compatibility = with existing non-standards compliant telepresence systems is not = required. The group will produce - Requirements and use cases - Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing = protocol enhancements and new protocol functionality required - Specification of a new protocol to support telepresence multi-streams = [if required] Goals and Milestones Nov 2010 Use Cases and Requirements to IESG as Informational RFC Nov 2010 March 2011 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC March 2011 Revise Charter [IF new protocol is not required] Nov 2011 Submit protocol draft to IESG as Proposed Standard RFC _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From allyn@cisco.com Wed Jun 2 17:54:03 2010 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 5A37228C0DB for ; Wed, 2 Jun 2010 17:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.64 X-Spam-Level: X-Spam-Status: No, score=-8.64 tagged_above=-999 required=5 tests=[AWL=1.659, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDOFM0D1Jryu for ; Wed, 2 Jun 2010 17:54: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 E5E6F3A691D for ; Wed, 2 Jun 2010 17:53:59 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEKaBkyrR7Hu/2dsb2JhbACDGZohanGmL4kQkQiBJoExgVFuBIJ+Sg X-IronPort-AV: E=Sophos;i="4.53,350,1272844800"; d="scan'208";a="259603157" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 03 Jun 2010 00:53:35 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o530raYJ015673; Thu, 3 Jun 2010 00:53:36 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 17:53:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 2 Jun 2010 17:53:34 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01817DFF@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7326301cb02af$ee00b17b$2b882f0a@eu.tandberg.int> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated charter/work description fortelepresencemulti-streams Thread-Index: AcsCqjjSwfLIbUWBQA+HnPLCAE5x3wABbUvDAAGRQ3A= References: <7326301cb02af$ee00b17b$2b882f0a@eu.tandberg.int> From: "Allyn Romanow (allyn)" To: =?utf-8?B?SMOla29uIERhaGxl?= , , X-OriginalArrivalTime: 03 Jun 2010 00:53:35.0972 (UTC) FILETIME=[32802240:01CB02B7] Subject: Re: [dispatch] Updated charter/work description fortelepresencemulti-streams 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, 03 Jun 2010 00:54:03 -0000 SGkgQWxleCBhbmQgSGFrb24sIA0KDQpJIHRoaW5rIHRoZSBpbnRlbnQgaGVyZSBpcyB0byBzYXkg dGhhdCB3ZSB3YW50IHRvIGNvdmVyIGN1cnJlbnQgdXNlIGNhc2VzIGFuZCBiZSBleHRlbnNpYmxl IGVub3VnaCB0byBjb3ZlciBuZXcgb25lcyB0aGF0IG1heSBhcmlzZS4gSSBkb24ndCB0aGluayBp dCB2YWx1YWJsZSB0byBleGhhdXN0aXZlbHkgZW51bWVyYXRlIHJlbGV2YW50IGRpbWVuc2lvbnMg b2YgdXNlIGNhc2VzIGluIHRoaXMgY2hhcnRlciBzdGF0ZW1lbnQgLSB0aGF0IGlzIGJldHRlciBs ZWZ0IHRvIHRoZSB1c2UgY2FzZSBkb2N1bWVudC4gDQoNCkhvdyB3b3VsZCBpdCBiZSB0byBzYXks DQoNCiJUaGlzIHJlcXVpcmVzIGNvbnNpZGVyaW5nIGN1cnJlbnQgd2lkZWx5IGRlcGxveWVkIHVz ZSBjYXNlcywgYXMgd2VsbCBhcyBjYXNlcyB0aGF0IGFyZSBleHBlY3RlZCB0byBiZSBpbXBsZW1l bnRlZCB1c2luZyB0aGUgcHJvdG9jb2wgZnJhbWV3b3JrIHByb2R1Y2VkIGJ5IHRoaXMgd29yayBp dGVtLiAgVGhlIG1ldGhvZG9sb2d5IGZvciBkZXNjcmliaW5nIHRoZSB2YXJpYWJsZXMgbXVzdCBh bGxvdyBleHRlbnNpYmlsaXR5IG9mIHRoZSB2YXJpYWJsZXMsIHNpbmNlIHRlbGVwcmVzZW5jZSBp cyBzdGlsbCBhIHlvdW5nIHRlY2hub2xvZ3kgYW5kIG1heSBoYXZlIHVzZSBjYXNlcyB0aGF0IGFy ZSBub3QgY3VycmVudGx5IGNvbnNpZGVyZWQuIg0KDQoNCkFsbHluDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlz cGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEjDpWtvbiBEYWhsZQ0KU2VudDog V2VkbmVzZGF5LCBKdW5lIDAyLCAyMDEwIDU6MDIgUE0NClRvOiBkaXNwYXRjaEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtkaXNwYXRjaF0gVXBkYXRlZCBjaGFydGVyL3dvcmsgZGVzY3JpcHRpb24g Zm9ydGVsZXByZXNlbmNlbXVsdGktc3RyZWFtcw0KDQoNCkFncmVlIHdpdGggQWxleCB0byBhIGxh cmdlIGV4dGVudCBpbiB0aGF0ICBzY2FsYWJpbGl0eSwgc2ltdWxjYXN0LCBwdWJsaXNoL3N1YnNj cmliZSBtYXkgYWxsIGJlIGFwcGxpY2FibGUgdG8gdGhlIHByb2JsZW0gYXQgaGFuZC4NCg0KSG93 ZXZlciBJIGRvIG5vdCB0aGluayB0aGUgQ2hhcnRlciBzaG91bGQganVtcCB0byBjb25jbHVzaW9u cyBvbiB3aGF0IGhhcHBlbnMgaW5zaWRlICJ0aGUgc2VydmVyIiB0aGF0IEFsZXggaXMgcmVmZXJy aW5nIHRvIGluIGhpcyBlbWFpbCAtIGF0IHRoaXMgcG9pbnQgSSBzdWdnZXN0IGxlYXZpbmcgdGhl c2UgZGV0YWlscyBvdXQgb2YgdGhlIGNoYXJ0ZXIsIHRvIG1ha2Ugc3VyZSBhbGwgb3B0aW9ucyBj YW4gYmUgaW52ZXN0aWdhdGVkLg0KDQotaA0KDQoNCg0KLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0t LQ0KRnJvbTogIkFsZXggRWxlZnRoZXJpYWRpcyIgPGFsZXhAdmlkeW8uY29tPg0KRGF0ZTogV2Vk LCBKdW4gMiwgMjAxMCAxNjoyMA0KU3ViamVjdDogW2Rpc3BhdGNoXSBVcGRhdGVkIGNoYXJ0ZXIv d29yayBkZXNjcmlwdGlvbiBmb3IgdGVsZXByZXNlbmNlbXVsdGktc3RyZWFtcw0KVG86ICJIw6Vr b24gRGFobGUiIDxoYWtvbi5kYWhsZUB0YW5kYmVyZy5jb20+DQpDYzogImRpc3BhdGNoQGlldGYu b3JnIiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQoNCklubGluZS4NCg0KT24gSnVuIDIsIDIwMTAsIGF0 IDk6NTEgUE0sIEjDpWtvbiBEYWhsZSB3cm90ZToNCg0KQSBjb21tZW50IG9uIHRoZSBmb2xsb3dp bmcgc2VudGVuY2UgaW4gdGhlIHVwZGF0ZWQgY2hhcnRlcjoNCg0K4oCcVGhpcyByZXF1aXJlcyBj b25zaWRlcmluZyBjdXJyZW50IHdpZGVseSBkZXBsb3llZCB1c2UgY2FzZXMsIHN1Y2ggYXMgc2lu Z2xlIGFuZCBtdWx0aXBsZSBzY3JlZW5zLCBtdWx0aS1wb2ludCwgU2NhbGFibGUgVmlkZW8gQ29k aW5nIChTVkMpLCBhcyB3ZWxsIGFzIGNhc2VzIHRoYXQgYXJlIGV4cGVjdGVkIHRvIGJlIGltcGxl bWVudGVkIHVzaW5nIHRoZSBwcm90b2NvbCBmcmFtZXdvcmsgcHJvZHVjZWQgYnkgdGhpcyB3b3Jr IGl0ZW0uICDigJ0NCg0KQWRkcmVzc2luZyB1c2UgY2FzZXMgc3VjaCBhcyBzaW5nbGUgYW5kIG11 bHRpcGxlIHNjcmVlbiBzeXN0ZW1zLCBhcyB3ZWxsIGFzIGJvdGggcG9pbnQtdG8tcG9pbnQgYW5k IG11bHRpLXBvaW50IGNhbGxpbmcgaXMgZ3JlYXQuICBIb3dldmVyIEkgZG8gbm90IHVuZGVyc3Rh bmQgd2h5IGEgc3BlY2lmaWMgdmlkZW8gY29kZWMgb3IgY29kaW5nIHRlY2huaXF1ZSBoYXMgYmVl biBhZGRlZCB0byB0aGUgc2FtZSBjb250ZXh0LiAgVGhlIGNoYXJ0ZXIgc2hvdWxkbuKAmXQgcmVj b21tZW5kIG9yIGxpbWl0IHRoZSB3b3JrIGZvciBhbnkgc3BlY2lmaWMgY29kZWMgKGl0IHNob3Vs ZCBiZSBjb2RlYyBhZ25vc3RpYyksICBhbmQgSSBzdWdnZXN0IHRoZSBjaGFydGVyIHNob3VsZCBi ZSBjaGFuZ2VkIHRvIGNvbXBseSB3aXRoIHRoaXMuDQoNClJpZ2h0LiBJIGJlbGlldmUgdGhhdCB0 aGUgY29ycmVjdCByZWZlcmVuY2UgaXMgdG8gYWx0ZXJuYXRpdmUgYXJjaGl0ZWN0dXJlcyBmb3Ig dGhlIHNlcnZlciBpbiBib3RoIHBvaW50LXRvLXBvaW50IGFuZCBtdWx0aS1wb2ludCBjYWxscywg d2hlcmUgc2NhbGFiaWxpdHkgKHdoaWNoIGluY2x1ZGVzIHNpbXVsY2FzdGluZywgcHlyYW1pZGFs IGNvZGluZyBzdWNoIGFzIFNWQywgYW5kIG11bHRpcGxlIGRlc2NyaXB0aW9uIGNvZGluZykgbGVu ZHMgaXRzZWxmIHRvIFZSVXMgKFZpZGVvIFJvdXRpbmcgVW5pdHMpIGFzIG9wcG9zZWQgdG8gTUNV cy4gVGhlIFZSVSBlbXBsb3lzIGEgInN1YnNjcmliZSIgbW9kZWwsIG1hZGUgcG9zc2libGUgYnkg c2NhbGFiaWxpdHksIGFuZCB3aGljaCB3b3JrcyBxdWl0ZSBkaWZmZXJlbnRseSB0aGFuIGFuIE1D VS4NCg0KLS1BbGV4DQoNCg0KDQotaA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRnJhOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkaXNwYXRjaC1ib3VuY2Vz QGlldGYub3JnPiBww6UgdmVnbmUgYXYgQWxseW4gUm9tYW5vdyAoYWxseW4pDQpTZW5kdDogb24g MDIuMDYuMjAxMCAxODoxMQ0KVGlsOiBkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hA aWV0Zi5vcmc+OyBtYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86bWFyeS5pZXRmLmJh cm5lc0BnbWFpbC5jb20+OyBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSkNCkVtbmU6IFtkaXNwYXRj aF0gVXBkYXRlZCBjaGFydGVyL3dvcmsgZGVzY3JpcHRpb24gZm9yIHRlbGVwcmVzZW5jZW11bHRp LXN0cmVhbXMNCkZvbGtzLA0KSGVyZSBpcyBhIHZlcnNpb24gb2YgdGhlIHdvcmsgZGVzY3JpcHRp b24gdGhhdCBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIG1hZGUgb24gdGhlIGZpcnN0IGRyYWZ0Lg0K VGhlIGNoYW5nZXMgaW5jbHVkZToNCjEuICAgICAgIENoYXJ0ZXIgc2VjdGlvbiwgcXVhbGlmaWNh dGlvbiB0aGF0IHdlIGFyZSB3b3JraW5nIG9uIFNJUC1iYXNlZCBzeXN0ZW1zDQoyLiAgICAgICBD aGFydGVyIHNlY3Rpb24sIG1pbm9yIHdvcmQgc21pdGhpbmcNCjMuICAgICAgIENoYXJ0ZXIgc2Vj dGlvbiwgcmVmZXJlbmNlIHRvIFJBSSBXRyB3aXRoIHJlbGV2YW50IHdvcmsNCjQuICAgICAgIFNj b3BlIHNlY3Rpb24sIGNsYXJpZmljYXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSByZXF1aXJlbWVu dHMNCjUuICAgICAgIFNjb3BlIHNlY3Rpb24sIHJlcGxhY2VtZW50IG9mIHNlY29uZCBwYXJhZ3Jh cGggcmVnYXJkaW5nIHRyZWF0bWVudCBvZiBub24tdmlkZW8gbm9uLWF1ZGlvIG1lZGlhIHR5cGVz DQo2LiAgICAgICBHb2FscyBhbmQgTWlsZXN0b25lcyDigJMgYWRkaXRpb24gb2YgYSBQcm9ibGVt IFN0YXRlbWVudCBkcmFmdA0KDQoNCkNvbW1lbnRzIHdlbGNvbWUNCg0KQWxseW4NCg0KTXVsdGkt c3RyZWFtcyBmb3IgVGVsZXByZXNlbmNlIERlc2NyaXB0aW9uIG9mIFdvcmsNCg0KDQoNCkJhY2tn cm91bmQNCk9uZSBicmFuY2ggb2YgdmlkZW8gY29uZmVyZW5jaW5nIGhhcyBldm9sdmVkIHRoYXQg aXMgZm9jdXNlZCBvbiBpbW1lcnNpdmUg4oCcYmVpbmcgdGhlcmXigJ0gZXhwZXJpZW5jZS4gIFJl ZmVycmVkIHRvIGluIHZhcmlvdXMgd2F5cyBzdWNoIGFzIHZpcnR1YWwgY29uZmVyZW5jaW5nLCB0 ZWxlcHJlc2VuY2Ugb3IgbWVkaWEgc3BhY2VzLCBlYXJseSBzeXN0ZW1zIHdlcmUgbWFpbmx5IHJl c2VhcmNoIHByb2plY3RzIG9yIGJ1c2luZXNzIHN5c3RlbXMgd2l0aCBsaW1pdGVkIGRlcGxveW1l bnRzLiAgSW4gcmVjZW50IHllYXJzIHRlbGVwcmVzZW5jZSBzeXN0ZW1zIGhhdmUgc2VlbiBjb25z aWRlcmFibGUgbWFya2V0IHN1Y2Nlc3MuICBGb2xsb3dpbmcgdGhlIG1vZGVsIG9mIGVhcmx5IHN5 c3RlbXMsIHRoZSBmaXJzdCB3YXZlIG9mIGNvbW1lcmNpYWwgc3lzdGVtcyBoYXZlIGJlZW4gdHlw aWNhbGx5IGxvY2F0ZWQgaW4gc3BlY2lhbGx5IGRlc2lnbmVkIHNpbmdsZS1wdXJwb3NlIHJvb21z IHdpdGggbXVsdGlwbGUgcmVsYXRpdmVseSBsYXJnZSBkaXNwbGF5cyBwZXJtaXR0aW5nIGxpZmUg c2l6ZSBpbWFnZSByZXByb2R1Y3Rpb24sIG11bHRpcGxlIGNhbWVyYXMsIGVuY29kZXJzLCBkZWNv ZGVycyBhbmQgbWljcm9waG9uZXMuICBUaGVzZSBzeXN0ZW1zIGhhdmUgc2V2ZXJhbCBpbXBvcnRh bnQgY2hhcmFjdGVyaXN0aWNzIHRoYXQgYXJlIGRpZmZlcmVudCBmcm9tIG1vcmUgdHJhZGl0aW9u YWwgdmlkZW8gY29uZmVyZW5jaW5nIHN5c3RlbXMuDQoNClRoZSBmaXJzdCBkaWZmZXJlbmNlIGNv bmNlcm5zIGNvbnRyb2xsaW5nIHRoZSB2aXN1YWwgdmlld3BvaW50IGluIG9yZGVyIHRvIGltcHJv dmUgcGFydGljaXBhbnQgbm9udmVyYmFsIGNvbW11bmljYXRpb24uIFRoZXNlIHN5c3RlbXMgcHJl c2VydmUgZXNzZW50aWFsIGdyb3VwIG1lZXRpbmcgY2hhcmFjdGVyaXN0aWNzIHN1Y2ggYXMgZXll IGNvbnRhY3QsIGdyb3VwIGdlc3R1cmVzLCBzZWF0aW5nIG9yZGVyIGFuZCBzcGF0aWFsIGF1ZGlv IGJ5IGNhcmVmdWxseSBvcmNoZXN0cmF0aW5nIHRoZSBtaWtpbmcgYW5kIGNhbWVyYSBhbmdsZXMg YXQgZWFjaCBvZiB0aGUgc2l0ZXMgLiBUaGlzIGlzIGRpc3RpbmN0IGZyb20gdGhlIG1vcmUgdHJh ZGl0aW9uYWwgYXBwcm9hY2ggd2hlcmUgdGhlIGdlb21ldHJpYyByZWxhdGlvbnNoaXAgYmV0d2Vl biBtZWRpYSBzdHJlYW1zIGlzIG5vdCB1c2VkIHRvIHByZXNlcnZlIGludGVyLXN0cmVhbSBjb21t dW5pY2F0aW9uIGFzcGVjdHMgc3VjaCBhcyBleWUgY29udGFjdCBhbmQgZ3JvdXAgZHluYW1pY3Mu DQoNCkEgc2Vjb25kIGRpZmZlcmVuY2UgaXMgbWFuaXB1bGF0aW9uIG9mIHRoZSBlbnZpcm9ubWVu dCB0byBpbXByb3ZlIGltbWVyc2lvbi4gIFdpdGggdGVsZXByZXNlbmNlIHN5c3RlbXMsIGNpbmVt YXRvZ3JhcGhpYyBhc3BlY3RzIG9mIHRoZSBsb2NhbCBlbnZpcm9ubWVudCByZXByb2R1Y3Rpb24g YXJlIGNhcmVmdWxseSBwbGFubmVkIGluY2x1ZGluZyBjb2xvciwgdGFibGUgc2hhcGUsIHNlYXRp bmcgYW5kIGxpZ2h0aW5nIHNvIHRoYXQgd2hlbiBjb21iaW5lZCB3aXRoIGxhcmdlIGhpZ2ggcXVh bGl0eSBkaXNwbGF5cywgYSBzdHJvbmcgc2Vuc2Ugb2YgYSAidHJvbXBlIGwnb2VpbCIgb3IgImJl aW5nIHRoZXJlIiBpbW1lcnNpdmUgZXhwZXJpZW5jZSBpcyBjcmVhdGVkLiAgVHlwaWNhbCB2aWRl byBjb25mZXJlbmNlIHN5c3RlbXMgZG8gbm90IGluY2x1ZGUgdGhlc2UgY29uc2lkZXJhdGlvbnMu DQoNCkFzIHRlbGVwcmVzZW5jZSB2aWRlbyBzeXN0ZW1zIGhhdmUgYmVjb21lIHN1Y2Nlc3NmdWwg aW4gdGhlIG1hcmtldCwgbWFudWZhY3R1cmVycyBoYXZlIHN0YXJ0ZWQgZXhwbG9yaW5nIGRlbGl2 ZXJ5IG9mIHRoZSBub252ZXJiYWwgY29tbXVuaWNhdGlvbiBhbmQgaW1tZXJzaXZlIHZhbHVlcyBv ZiB0ZWxlcHJlc2VuY2UgdmlhIHNtYWxsZXIsIGxlc3MgZXhwZW5zaXZlIGFuZCBtb3JlIGZsZXhp YmxlIHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW1zIGZvciBhIHZhcmlldHkgb2YgdmVudWVzLCBz dWNoIGFzIGluZGl2aWR1YWwgb2ZmaWNlcywgaG9tZXMgYW5kIGtpb3Nrcy4gVGhlc2UgYXJlIGFs c28gIHRlbGVwcmVzZW5jZSBzeXN0ZW1zLCBzaW5jZSB0aGUgYXVkaW8gYW5kIHZpZGVvIHF1YWxp dHkgaXMgaGlnaCBlbm91Z2ggdG8gYWxsb3cgY2xlYXIgaW1hZ2UgcmVwcm9kdWN0aW9uIGZvciBu b252ZXJiYWwgY29tbXVuaWNhdGlvbiwgdGhleSBhcmUgYWJsZSB0byBzZW5kIGFuZCByZWNlaXZl IG11bHRpcGxlIG1lZGlhIHN0cmVhbXMsIGFuZCBsYXJnZSBjb29yZGluYXRlZCBtdWx0aSBpbWFn ZSBkaXNwbGF5cyBhcmUgYXZhaWxhYmxlIGZvciBpbW1lcnNpdmUgaW5zdGFsbGF0aW9ucy4gICBB cyB0aGUgaW5kdXN0cnkgZGV2ZWxvcHMsIHRoZSBsaW5lIGJldHdlZW4gdGVsZXByZXNlbmNlIGFu ZCB2aWRlbyBjb25mZXJlbmNpbmcgbWF5IGJlY29tZSBibHVycmVkIGFzIG5vbnZlcmJhbCBjb21t dW5pY2F0aW9uIGFuZCBpbW1lcnNpdmUgaW5zdGFsbGF0aW9ucyBiZWNvbWUgYnJvYWRseSBhdmFp bGFibGUuDQoNClByb2JsZW0NCkFsdGhvdWdoIHRlbGVwcmVzZW5jZSBzeXN0ZW1zIGFyZSBiYXNl ZCBvbiBvcGVuIHN0YW5kYXJkcyBzdWNoIGFzIFJUUCwgU0lQLCBILjI2NCwgSC4zMjMgc3VpdGUs IHRoZXkgY2Fubm90IGVhc2lseSBpbnRlcm9wZXJhdGUgd2l0aCBlYWNoIG90aGVyIHdpdGhvdXQg b3BlcmF0b3IgYXNzaXN0YW5jZSBhbmQgZXhwZW5zaXZlIGFkZGl0aW9uYWwgZXF1aXBtZW50IHRo YXQgdHJhbnNsYXRlcyBmcm9tIG9uZSB2ZW5kb3IgdG8gYW5vdGhlci4gSXQgd291bGQgYmUgbGlr ZSBoYXZpbmcgdG8gbWFrZSBzdXJlIGFsbCBwYXJ0aWVzIGFyZSBvbiB0aGUgc2FtZSBlcXVpcG1l bnQgKGFuZCBuZXR3b3JrKSB3aGVuIG1ha2luZyBhIHRlbGVwaG9uZSBjYWxsLiAgQSBtYWpvciBm YWN0b3IgaW4gdGhlIGluYWJpbGl0eSBvZiBUZWxlcHJlc2VuY2Ugc3lzdGVtcyB0byB3b3JrIHdp dGggZWFjaCBvdGhlciBpcyB0aGF0IHRoZXJlIGlzIG5vIHN0YW5kYXJkIGRlc2NyaXB0aW9uIG9m IHRoZSBtdWx0aXBsZSBzdHJlYW1zIHRoYXQgY29tcHJpc2UgdGhlIG1lZGlhIGZsb3dzLg0KDQpG b3IgZXhhbXBsZSwgaW4gYSBtdWx0aXBsZSBzY3JlZW4gY29uZmVyZW5jZSwgdGhlIHZpZGVvIGFu ZCBhdWRpbyBzdHJlYW1zIHNlbnQgZnJvbSByZW1vdGUgcGFydGljaXBhbnRzIG11c3QgYmUgdW5k ZXJzdG9vZCBieSByZWNlaXZlcnMgc28gdGhhdCB0aGV5IGNhbiBiZSBwcmVzZW50ZWQgaW4gYSBj b2hlcmVudCBhbmQgbGlmZS1saWtlIG1hbm5lci4gVGhpcyBpbmNsdWRlcyB0aGUgYWJpbGl0eSB0 byBwcmVzZW50IHRoZSByZW1vdGUgcGFydGljaXBhbnRzIGF0IHRoZWlyIHRydWUgc2l6ZSBmb3Ig dGhlaXIgYXBwYXJlbnQgZGlzdGFuY2UsIHdoaWxlIG1haW50YWluaW5nIGNvcnJlY3QgZXllIGNv bnRhY3QsIGdlc3RpY3VsYXIgY3VlcywgYW5kIHNpbXVsdGFuZW91c2x5IHByb3ZpZGluZyBhIHNw YXRpYWwgYXVkaW8gc291bmQgc3RhZ2UgY29uc2lzdGVudCB3aXRoIHRoZSB2aWRlbyBwcmVzZW50 YXRpb24uICBUaGUgcmVjZWl2aW5nIGRldmljZSB0aGF0IGRlY2lkZXMgaG93IHRvIGRpc3BsYXkg dGhlIGluY29taW5nIGluZm9ybWF0aW9uIG5lZWRzIHRvIHVuZGVyc3RhbmQgYSBudW1iZXIgb2Yg dmFyaWFibGVzIHN1Y2ggYXMgdGhlIHNwYXRpYWwgcG9zaXRpb24gb2YgdGhlIHNwZWFrZXIsIHRo ZSBmaWVsZCBvZiB2aWV3IG9mIHRoZSBjYW1lcmFzLCB0aGUgY2FtZXJhIHpvb20sIHdoaWNoIG1l ZGlhIHN0cmVhbSBpcyByZWxhdGVkIHRvIGVhY2ggb2YgdGhlIGRpc3BsYXlzLCBldGMuDQoNCkNo YXJ0ZXINClRoZSBUZWxlcHJlc2VuY2UgTXVsdGktU3RyZWFtcyB3b3JrIGl0ZW0gaW4gRElTUEFU Q0ggaXMgY2hhcnRlcmVkIHRvIGRlZmluZSBhbmQgc3BlY2lmeSBmb3IgU0lQLWJhc2VkIHN5c3Rl bXMgdGhlIGNvbnRlbnQgb2YgbWVkaWEgbXVsdGktc3RyZWFtIG1lc3NhZ2VzIGFuZCB0aGUgd2F5 IHRoZXNlIHdpbGwgYmUgdHJhbnNwb3J0ZWQuDQoNClRoaXMgd29yayB3aWxsIHByb3ZpZGUgYSBz dGFuZGFyZCBmb3IgdGhlIGV4Y2hhbmdlIG9mIG1lZGlhIHNlbWFudGljIGluZm9ybWF0aW9uIHRo YXQgd2lsbCBmb3N0ZXIgaW50ZXJvcGVyYWJsZSBlbmQgc3RhdGlvbnMgYW5kIGNvbmZlcmVuY2Ug YnJpZGdlcy4gSXQgd2lsbCBzcGVjaWZ5ICB2YXJpYWJsZXMgdGhhdCBkZXNjcmliZSB0aGUgc2Vt YW50aWNzIG9mIHRoZSBtZWRpYSBzdHJlYW1zIGFuZCB0aGUgcmVjb21tZW5kZWQgYmVoYXZpb3Ig dG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpUaGlzIHJlcXVpcmVzIGNvbnNpZGVyaW5n IGN1cnJlbnQgd2lkZWx5IGRlcGxveWVkIHVzZSBjYXNlcywgc3VjaCBhcyBzaW5nbGUgYW5kIG11 bHRpcGxlIHNjcmVlbnMsIG11bHRpLXBvaW50LCBTY2FsYWJsZSBWaWRlbyBDb2RpbmcgKFNWQyks IGFzIHdlbGwgYXMgY2FzZXMgdGhhdCBhcmUgZXhwZWN0ZWQgdG8gYmUgaW1wbGVtZW50ZWQgdXNp bmcgdGhlIHByb3RvY29sIGZyYW1ld29yayBwcm9kdWNlZCBieSB0aGlzIHdvcmsgaXRlbS4gIFRo ZSBtZXRob2RvbG9neSBmb3IgZGVzY3JpYmluZyB0aGUgdmFyaWFibGVzIG11c3QgYWxsb3cgZXh0 ZW5zaWJpbGl0eSBvZiB0aGUgdmFyaWFibGVzLCBzaW5jZSB0ZWxlcHJlc2VuY2UgaXMgc3RpbGwg YSB5b3VuZyB0ZWNobm9sb2d5IGFuZCBtYXkgaGF2ZSB1c2UgY2FzZXMgdGhhdCBhcmUgbm90IGN1 cnJlbnRseSBjb25zaWRlcmVkLg0KDQpUaGUgd29yayBpdGVtIHdpbGwgaWRlbnRpZnkgdXNlIGNh c2VzLCBkZWZpbmUgcmVxdWlyZW1lbnRzLCBhbmQgZGVmaW5lIGEgbWV0aG9kIGZvciBkZXNjcmli aW5nIGFuZCB0cmFuc3BvcnRpbmcgaW5mb3JtYXRpb24gYWJvdXQgbXVsdGlwbGUgbWVkaWEgc3Ry ZWFtcywgaW5jbHVkaW5nIGEgc3BlY2lmaWNhdGlvbiBvZiB2YXJpYWJsZXMgcmVxdWlyZWQgdG8g c3VwcG9ydCB0aGUgdXNlIGNhc2VzLiBUaGlzIHdvcmsgaXRlbSB3aWxsIGNvbnNpZGVyIHRoZSBy ZXVzZSBvZiBleGlzdGluZyBJRVRGIHByb3RvY29scyBhbmQgcHJvZHVjZSBhbiBhcmNoaXRlY3R1 cmUvcHJvdG9jb2wgZnJhbWV3b3JrIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhlIHByb3RvY29scyBy ZXF1aXJlZCB0byBiZSBpbXBsZW1lbnRlZCB0byBzdXBwb3J0IHRoaXMgZnVuY3Rpb25hbGl0eS4g IFRoZSBkb2N1bWVudCB3aWxsIGlkZW50aWZ5IGFueSBlbmhhbmNlbWVudHMgcmVxdWlyZWQgdG8g ZXhpc3RpbmcgcHJvdG9jb2xzIGFzIHdlbGwgYXMgZGVzY3JpYmluZyBuZXcgcHJvdG9jb2wocykg Zm9yIGludGVyb3BlcmFibGUgbXVsdGktc3RyZWFtcyBuZWdvdGlhdGlvbiB0aGF0IG1heSBiZSBy ZXF1aXJlZC4NCg0KUmVsZXZhbnQgd29yayB0byBiZSBkcmF3biB1cG9uIGhhcyBiZWVuIGRvbmUg aW4gWENPTiwgTU1VU0lDLCBBVlQsIGFuZCBGRUNmcmFtZS4NCg0KU2NvcGUNClRoZSBzY29wZSBp bmNsdWRlcyBib3RoIHN5c3RlbXMgdGhhdCBwcm92aWRlIGEgZnVsbHkgaW1tZXJzaXZlIGV4cGVy aWVuY2UsIGFuZCBzeXN0ZW1zIHRoYXQgaW50ZXJ3b3JrIHdpdGggdGhlbSBhbmQgdGhlcmVmb3Jl IG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgc2FtZSBtdWx0aXBsZSBzdHJlYW0gc2VtYW50aWNzLg0K DQoNClRoZSBmb2N1cyBvZiB0aGlzIHdvcmsgaXMgb24gYXVkaW8gYW5kIHZpZGVvIG11bHRpcGxl IHN0cmVhbXMuICBPdGhlciBtZWRpYSB0eXBlcyBtYXkgYmUgY29uc2lkZXJlZCwgaG93ZXZlciBk ZXZlbG9wbWVudCBvZiBtZXRob2RvbG9naWVzIGZvciB0aGVtIGlzIG5vdCB3aXRoaW4gdGhlIHNj b3BlIG9mIHRoaXMgd29yay4NCg0KSW50ZXJvcGVyYXRpb24gd2l0aCBzdGFuZGFyZHMgY29tcGxp YW50IHN5c3RlbXMgaXMgcmVxdWlyZWQsIHN1Y2ggYXMgU0lQLWJhc2VkIHZpZGVvIGNvbmZlcmVu Y2luZyBzeXN0ZW1zLiAgSG93ZXZlciwgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCBleGlz dGluZyBub24tc3RhbmRhcmRzIGNvbXBsaWFudCB0ZWxlcHJlc2VuY2Ugc3lzdGVtcyBpcyBub3Qg cmVxdWlyZWQuDQoNCg0KDQpUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlDQotIFJlcXVpcmVtZW50cyBh bmQgdXNlIGNhc2VzDQoNCi0gQXJjaGl0ZWN0dXJhbCBGcmFtZXdvcmsgZGVzY3JpYmluZyB0aGUg cHJvdG9jb2xzIHJlcXVpcmVkIHRvIGJlIGltcGxlbWVudGVkIHRvIHN1cHBvcnQgdGhpcyBmdW5j dGlvbmFsaXR5IGFuZCBpZGVudGlmeWluZyBleGlzdGluZyBwcm90b2NvbCBlbmhhbmNlbWVudHMg YW5kIG5ldyBwcm90b2NvbCBmdW5jdGlvbmFsaXR5IHJlcXVpcmVkDQoNCi0gU3BlY2lmaWNhdGlv biBvZiBhIG5ldyBwcm90b2NvbCB0byBzdXBwb3J0IHRlbGVwcmVzZW5jZSBtdWx0aS1zdHJlYW1z IFtpZiByZXF1aXJlZF0NCg0KR29hbHMgYW5kIE1pbGVzdG9uZXMNCk5vdiAyMDEwDQoNCg0KVXNl IENhc2VzIGFuZCBSZXF1aXJlbWVudHMgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQw0KDQpO b3YgMjAxMA0KTWFyY2ggMjAxMQ0KDQpQcm9ibGVtIFN0YXRlbWVudCB0byBJRVNHIGFzIEluZm9y bWF0aW9uYWwgUkZDDQpBcmNoaXRlY3R1cmUgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsIFJGQw0K DQpNYXJjaCAyMDExDQoNClJldmlzZSBDaGFydGVyIFtJRiBuZXcgcHJvdG9jb2wgaXMgbm90IHJl cXVpcmVkXQ0KDQpOb3YgMjAxMQ0KDQpTdWJtaXQgcHJvdG9jb2wgZHJhZnQgdG8gSUVTRyBhcyBQ cm9wb3NlZCBTdGFuZGFyZCBSRkMNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0 Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K From gao.yang2@zte.com.cn Wed Jun 2 18:44:26 2010 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 BB07C3A68BB for ; Wed, 2 Jun 2010 18:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.316 X-Spam-Level: X-Spam-Status: No, score=-96.316 tagged_above=-999 required=5 tests=[AWL=-1.881, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 3LWoBrQpbRSM for ; Wed, 2 Jun 2010 18:44:22 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 20E903A6870 for ; Wed, 2 Jun 2010 18:44:19 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 58071992332426; Thu, 3 Jun 2010 09:38:12 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 2748.1142583116; Thu, 3 Jun 2010 09:44:00 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5313Gb5011414; Thu, 3 Jun 2010 09:09:47 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01761012@xmb-sjc-221.amer.cisco.com> To: "Allyn Romanow (allyn)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 3 Jun 2010 09:06:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-03 09:09:45, Serialize complete at 2010-06-03 09:09:45 Content-Type: multipart/alternative; boundary="=_alternative 0006548B48257737_=" X-MAIL: mse2.zte.com.cn o5313Gb5011414 Cc: IETF DISPATCH list Subject: Re: [dispatch] Multi-streams for telepresence description of work 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, 03 Jun 2010 01:44:27 -0000 This is a multipart message in MIME format. --=_alternative 0006548B48257737_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQWxseW4sDQoNClN1cmUuIFdlIGNhbiBkbyB0aGUgc3BsaXRpbmcgZXZhbHVhdGlvbiBsYXRl ciBhcyB5b3Ugc2FpZC4NCg0KQ2hlZXJzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIg ICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQoiQWxseW4gUm9tYW5vdyAo YWxseW4pIiA8YWxseW5AY2lzY28uY29tPiANCjIwMTAtMDYtMDMgMDA6MTUNCg0KytW8/sjLDQo8 Z2FvLnlhbmcyQHp0ZS5jb20uY24+DQqzrcvNDQoiSUVURiBESVNQQVRDSCBsaXN0IiA8ZGlzcGF0 Y2hAaWV0Zi5vcmc+DQrW98ziDQpSRTogW2Rpc3BhdGNoXSBNdWx0aS1zdHJlYW1zIGZvciB0ZWxl cHJlc2VuY2UgZGVzY3JpcHRpb24gb2Ygd29yaw0KDQoNCg0KDQoNCg0KSGkgR2FvLA0KIA0KSSBo YWQgYSBjaGFuY2UgdG8gdGFsayB3aXRoIE1hcnkgYWJvdXQgeW91ciBpZGVhIHRvIHNwbGl0IHVw IHRoZSB3b3JrLCBhbmQgDQpzaGUgY29uZmlybWVkIHRoYXQgaXQgaXMgZ29vZCBwcmFjdGljZSBp biBnZW5lcmFsIHRvIGRvIHNvLCBidXQgd2UgdGhvdWdodCANCml0IGlzIGFzIHlldCB0b28gZWFy bHkgdG8gc3BsaXQgdXAgdGhlIG11bHRpLXN0cmVhbSB3b3JrLiAgQXMgd2UgcHJvZ3Jlc3MgDQp3 aXRoIHVzZSBjYXNlcywgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHJlcXVpcmVtZW50cywgd2Ugd2ls bCBiZSBhYmxlIHRvIHNlZSANCmJldHRlciBpZiB0aGUgdG9waWMgc2hvdWxkIGJlIHNwbGl0IHVw Lg0KIA0KQmVzdCByZWdhcmRzLA0KQWxseW4NCiANCkZyb206IGdhby55YW5nMkB6dGUuY29tLmNu IFttYWlsdG86Z2FvLnlhbmcyQHp0ZS5jb20uY25dIA0KU2VudDogVHVlc2RheSwgTWF5IDE4LCAy MDEwIDEwOjMzIFBNDQpUbzogQWxseW4gUm9tYW5vdyAoYWxseW4pDQpDYzogSUVURiBESVNQQVRD SCBsaXN0DQpTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBNdWx0aS1zdHJlYW1zIGZvciB0ZWxlcHJl c2VuY2UgZGVzY3JpcHRpb24gb2Ygd29yaw0KIA0KDQpIaSwgDQoNCkkgaGF2ZSB0d28gbGV2ZWwg b2YgY29tbWVudHMsIA0KDQoxLiBGZWVsaW5nIGZvciB0aGUgdG9waWMgDQpUZWNobmljYWxseSwg SSBhbSBxdWl0IGdsYWQgdG8gc2VlIHN1Y2ggZGlzY3Vzc2lvbiBhYm91dCB0ZWxlcHJlc2VuY2Us IA0Kd2hpY2ggaXMgdHJhaWxibGF6ZXIgZm9yIFZSKFZpcnR1YWwgUmVhbGl0eSkgcHJvZHVjdGlv bi4gDQoNCjIuIEFib3V0IHRoZSBjaGFydGVyIFdHIA0KT25lIHJldm9sdXRpb25hcnkgYXBwbGlj YXRpb24sIHN1Y2ggdGVsZXByZXNlbmNlLCB3b3VsZCBjb3ZlciBiYXNpYyANCnByb3RvY29sIGxl dmVsLCBhcHBsaWNhdGlvbiBjb250cm9sIGxldmVsLCBhbmQgaW50ZXJ3b3JraW5nIGlzc3VlLiAN Cg0KSWYgdGhlIHdvcmsgaXMganVzdCBmb2N1c2VkIG9uIHB1cmUgaW50ZXJ3b3JraW5nIGlzc3Vl LCB0aGVuIHRoZSB0b3BpY3MgDQpjYW4gYmUgZGl2aWRlZCBpbnRvIHNtYWxsZXIgb25lLCB3aGlj aCBtaWdodCBiZSBpbiBvdGhlciBiYXNpYyBwcm90b2NvbHMnIA0KV0cncyBzY29wZS4gQnV0IGlm IHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgaXMgbmV3LCBhbmQgaGFzIHNvbWUgbmV3IA0KY2hhcmFj dGVyaXN0aWMsIG1vcmUgd29yayBzaG91bGQgYmUgcHJvcG9zZWQuIA0KDQpJZiB0aGUgd29yayBp cyBhbHNvIGZvY3VzZWQgb24gdGVsZXByZXNlbmNlIGFwcGxpY2F0aW9uLCB3aGljaCBpcyBhIA0K Y29uZmVyZW5jaW5nIHN5c3RlbSwgdGhlIHhjb24gV0cgbWlnaHQgYmUgcHJvcGVyIG9uZSBmb3Ig YXBwbGljYXRpb24gbGV2ZWwgDQpkZWZpbml0aW9uLiANCg0KSWYgdGhlIGNoYXJ0ZXIgYWxzbyB3 YW50IHRvIHRhbGsgdGhlIGVzZW50aWFsIGFzcGVjdCBvZiB0ZWxlcHJlc2VuY2Uob3IgDQptb3Jl IGFic3RyYWN0bHksIGFib3V0IFZSKSwgc3VjaCBhcyBob3cgdG8gdXNpbmcgU0RQLCBvciByZWxh dGl2ZSBwcm90b2NvbCANCnRvIGRlc2NyaWJlIHRoZSBzdHJlYW1zIGFuZCBpdCdzIGNvbGxhYm9y YXRpb24sIGl0IHdvdWxkIGJlIHF1aXRlIG5ldyANCnRvcGljLiBPbmUgbmV3IFdHIG1pZ2h0IGJl IGJldHRlci4gDQoNCg0KSSBmaW5kIHRoZSBjaGFydGVyIHNlZW1zIGNvdmVycyBhbGwgdGhlIHRo cmVlIHRoaW5nLiBTbywgSSBzdWdnZXN0IHlvdSANCmNsYXNzaWZ5IHN1Y2ggZGlmZmVyZW50IGxl dmVsIHJlcXVpcmVtZW50LiBUaGVuLCB3ZSBtYXkgZmluZCB3aGljaCBwYXJ0IGlzIA0KcHJvcGVy IGZvciB3aGljaCBXRywgYW5kIHdoaWNoIHBhcnQgc2hvdWxkIGJlIGNvdmVyZWQgYnkgbmV3IFdH LiANCg0KVGhhbmtzLCANCg0KR2FvIA0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KWmlwICAgIDogMjEwMDEyDQpUZWwgICAgOiA4NzIxMQ0KVGVsMiAgIDooKzg2KS0wMjUt NTI4NzcyMTENCmVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PSANCg0KDQoiQWxseW4gUm9tYW5vdyAoYWxseW4pIiA8YWxseW5A Y2lzY28uY29tPiANCreivP7IyzogIGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEwLTA1 LTE5IDAyOjMwIA0KDQoNCsrVvP7Iyw0KIklFVEYgRElTUEFUQ0ggbGlzdCIgPGRpc3BhdGNoQGll dGYub3JnPiANCrOty80NCg0K1vfM4g0KW2Rpc3BhdGNoXSBNdWx0aS1zdHJlYW1zIGZvciB0ZWxl cHJlc2VuY2UgZGVzY3JpcHRpb24gb2Ygd29yaw0KIA0KDQoNCg0KDQoNCg0KDQoNCkhpIEZvbGtz LCANCiAgDQpNYW55IG9mIHlvdSBhcmUgYXdhcmUgb2YgdGVsZXByZXNlbmNlIHN5c3RlbXMgKHZp ZGVvIGNvbmZlcmVuY2luZyBvbiANCnN0ZXJvaWRzLi46KSwgZmV3ZXIgcHJvYmFibHkgYXJlIGF3 YXJlIG9mIHRoZSBmYWN0IHRoYXQgdGhlIGN1cnJlbnQgDQpzeXN0ZW1zIGFyZSBub3QgaW50ZXJv cGVyYWJsZSB3aXRoIGVhY2ggb3RoZXIuIEFmdGVyIHRhbGtpbmcgd2l0aCBNYXJ5IGFuZCANCkN1 bGxlbiwgd2UgaGF2ZSBhIHJvdWdoIGRyYWZ0IG9mIGEgY2hhcnRlciB0byB3b3JrIG9uIHRoaXMg cHJvYmxlbSBpbiANCkRJU1BBVENILCAgZm9yIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlz dC4gDQogIA0KV2UgZG9uoa90IHlldCBrbm93IHdoZXRoZXIgYSB3b3JraW5nIGdyb3VwIHdvdWxk IG5lZWQgdG8gYmUgc3B1biBvdXQgb3IgDQpub3QgqEMgdGhhdCB3aWxsIGJlIGNsYXJpZmllZCBh cyB3ZSBnby4gDQogIA0KV2UgdGhpbmsgdGhlcmUgaXMgZW5vdWdoIGJhY2tncm91bmQgaW5mbyBp biB0aGUgd29yayBkZXNjcmlwdGlvbiB0byBzdGFydCANCmEgZGlzY3Vzc2lvbiwgYW5kIHBsYW4g dG8gc2VuZCBvdXQgdXNlIGNhc2VzIGZvciBkaXNjdXNzaW9uIHNob3J0bHkuIA0KICANCldobyBp cyB0aGUgd2U/IFNldmVyYWwgbWFrZXJzIGFuZCBwcm92aWRlcnMgb2YgdGVsZXByZXNlbmNlIHN5 c3RlbXMgaGF2ZSANCmdvdHRlbiB0b2dldGhlciB0byBkZWZpbmUgdGhlIG1haW4gcHJvYmxlbSBp biBpbnRlcm9wZXJhYmlsaXR5IKhDIHRoZSANCmhhbmRsaW5nIG9mIG11bHRpLXN0cmVhbXMuIA0K ICANClRoYW5rcyBmb3IgeW91ciB0aG91Z2h0cy0gDQpBbGx5biANCiAgDQogIA0KDQpNdWx0aS1z dHJlYW1zIGZvciBUZWxlcHJlc2VuY2UgRGVzY3JpcHRpb24gb2YgV29yayANCiAgDQogDQoNCiAg DQpCYWNrZ3JvdW5kIA0KT25lIGJyYW5jaCBvZiB2aWRlbyBjb25mZXJlbmNpbmcgaGFzIGV2b2x2 ZWQgdGhhdCBpcyBmb2N1c2VkIG9uIGltbWVyc2l2ZSANCqGwYmVpbmcgdGhlcmWhsSBleHBlcmll bmNlLiAgUmVmZXJyZWQgdG8gaW4gdmFyaW91cyB3YXlzIHN1Y2ggYXMgdmlydHVhbCANCmNvbmZl cmVuY2luZywgdGVsZXByZXNlbmNlIG9yIG1lZGlhIHNwYWNlcywgZWFybHkgc3lzdGVtcyB3ZXJl IG1haW5seSANCnJlc2VhcmNoIHByb2plY3RzIG9yIGJ1c2luZXNzIHN5c3RlbXMgd2l0aCBsaW1p dGVkIGRlcGxveW1lbnRzLiAgSW4gcmVjZW50IA0KeWVhcnMgdGVsZXByZXNlbmNlIHN5c3RlbXMg aGF2ZSBzZWVuIGNvbnNpZGVyYWJsZSBtYXJrZXQgc3VjY2Vzcy4gDQpGb2xsb3dpbmcgdGhlIG1v ZGVsIG9mIGVhcmx5IHN5c3RlbXMsIHRoZSBmaXJzdCB3YXZlIG9mIGNvbW1lcmNpYWwgc3lzdGVt cyANCmhhdmUgYmVlbiB0eXBpY2FsbHkgbG9jYXRlZCBpbiBzcGVjaWFsbHkgZGVzaWduZWQgc2lu Z2xlLXB1cnBvc2Ugcm9vbXMgDQp3aXRoIG11bHRpcGxlIHJlbGF0aXZlbHkgbGFyZ2UgZGlzcGxh eXMgcGVybWl0dGluZyBsaWZlIHNpemUgaW1hZ2UgDQpyZXByb2R1Y3Rpb24sIG11bHRpcGxlIGNh bWVyYXMsIGVuY29kZXJzLCBkZWNvZGVycyBhbmQgbWljcm9waG9uZXMuICBUaGVzZSANCnN5c3Rl bXMgaGF2ZSBzZXZlcmFsIGltcG9ydGFudCBjaGFyYWN0ZXJpc3RpY3MgdGhhdCBhcmUgZGlmZmVy ZW50IGZyb20gDQptb3JlIHRyYWRpdGlvbmFsIHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiAg IA0KICANClRoZSBmaXJzdCBkaWZmZXJlbmNlIGNvbmNlcm5zIGNvbnRyb2xsaW5nIHRoZSB2aXN1 YWwgdmlld3BvaW50IGluIG9yZGVyIHRvIA0KaW1wcm92ZSBwYXJ0aWNpcGFudCBub252ZXJiYWwg Y29tbXVuaWNhdGlvbi4gVGhlc2Ugc3lzdGVtcyBwcmVzZXJ2ZSANCmVzc2VudGlhbCBncm91cCBt ZWV0aW5nIGNoYXJhY3RlcmlzdGljcyBzdWNoIGFzIGV5ZSBjb250YWN0LCBncm91cCANCmdlc3R1 cmVzLCBzZWF0aW5nIG9yZGVyIGFuZCBzcGF0aWFsIGF1ZGlvIGJ5IGNhcmVmdWxseSBvcmNoZXN0 cmF0aW5nIHRoZSANCm1pa2luZyBhbmQgY2FtZXJhIGFuZ2xlcyBhdCBlYWNoIG9mIHRoZSBzaXRl cyAuIFRoaXMgaXMgZGlzdGluY3QgZnJvbSB0aGUgDQptb3JlIHRyYWRpdGlvbmFsIGFwcHJvYWNo IHdoZXJlIHRoZSBnZW9tZXRyaWMgcmVsYXRpb25zaGlwIGJldHdlZW4gbWVkaWEgDQpzdHJlYW1z IGlzIG5vdCB1c2VkIHRvIHByZXNlcnZlIGludGVyLXN0cmVhbSBjb21tdW5pY2F0aW9uIGFzcGVj dHMgc3VjaCBhcyANCmV5ZSBjb250YWN0IGFuZCBncm91cCBkeW5hbWljcy4gICANCiAgDQpBIHNl Y29uZCBkaWZmZXJlbmNlIGlzIG1hbmlwdWxhdGlvbiBvZiB0aGUgZW52aXJvbm1lbnQgdG8gaW1w cm92ZSANCmltbWVyc2lvbi4gIFdpdGggdGVsZXByZXNlbmNlIHN5c3RlbXMsIGNpbmVtYXRvZ3Jh cGhpYyBhc3BlY3RzIG9mIHRoZSANCmxvY2FsIGVudmlyb25tZW50IHJlcHJvZHVjdGlvbiBhcmUg Y2FyZWZ1bGx5IHBsYW5uZWQgaW5jbHVkaW5nIGNvbG9yLCANCnRhYmxlIHNoYXBlLCBzZWF0aW5n IGFuZCBsaWdodGluZyBzbyB0aGF0IHdoZW4gY29tYmluZWQgd2l0aCBsYXJnZSBoaWdoIA0KcXVh bGl0eSBkaXNwbGF5cywgYSBzdHJvbmcgc2Vuc2Ugb2YgYSAidHJvbXBlIGwnb2VpbCIgb3IgImJl aW5nIHRoZXJlIiANCmltbWVyc2l2ZSBleHBlcmllbmNlIGlzIGNyZWF0ZWQuICBUeXBpY2FsIHZp ZGVvIGNvbmZlcmVuY2Ugc3lzdGVtcyBkbyBub3QgDQppbmNsdWRlIHRoZXNlIGNvbnNpZGVyYXRp b25zLiANCiAgDQpBcyB0ZWxlcHJlc2VuY2UgdmlkZW8gc3lzdGVtcyBoYXZlIGJlY29tZSBzdWNj ZXNzZnVsIGluIHRoZSBtYXJrZXQsIA0KbWFudWZhY3R1cmVycyBoYXZlIHN0YXJ0ZWQgZXhwbG9y aW5nIGRlbGl2ZXJ5IG9mIHRoZSBub252ZXJiYWwgDQpjb21tdW5pY2F0aW9uIGFuZCBpbW1lcnNp dmUgdmFsdWVzIG9mIHRlbGVwcmVzZW5jZSB2aWEgc21hbGxlciwgbGVzcyANCmV4cGVuc2l2ZSBh bmQgbW9yZSBmbGV4aWJsZSB2aWRlbyBjb25mZXJlbmNpbmcgc3lzdGVtcyBmb3IgYSB2YXJpZXR5 IG9mIA0KdmVudWVzLCBzdWNoIGFzIGluZGl2aWR1YWwgb2ZmaWNlcywgaG9tZXMgYW5kIGtpb3Nr cy4gVGhlc2UgYXJlIGFsc28gDQp0ZWxlcHJlc2VuY2Ugc3lzdGVtcywgc2luY2UgdGhlIGF1ZGlv IGFuZCB2aWRlbyBxdWFsaXR5IGlzIGhpZ2ggZW5vdWdoIHRvIA0KYWxsb3cgY2xlYXIgaW1hZ2Ug cmVwcm9kdWN0aW9uIGZvciBub252ZXJiYWwgY29tbXVuaWNhdGlvbiwgdGhleSBhcmUgYWJsZSAN CnRvIHNlbmQgYW5kIHJlY2VpdmUgbXVsdGlwbGUgbWVkaWEgc3RyZWFtcywgYW5kIGxhcmdlIGNv b3JkaW5hdGVkIG11bHRpIA0KaW1hZ2UgZGlzcGxheXMgYXJlIGF2YWlsYWJsZSBmb3IgaW1tZXJz aXZlIGluc3RhbGxhdGlvbnMuICAgQXMgdGhlIA0KaW5kdXN0cnkgZGV2ZWxvcHMsIHRoZSBsaW5l IGJldHdlZW4gdGVsZXByZXNlbmNlIGFuZCB2aWRlbyBjb25mZXJlbmNpbmcgDQptYXkgYmVjb21l IGJsdXJyZWQgYXMgbm9udmVyYmFsIGNvbW11bmljYXRpb24gYW5kIGltbWVyc2l2ZSBpbnN0YWxs YXRpb25zIA0KYmVjb21lIGJyb2FkbHkgYXZhaWxhYmxlLiANCiAgDQpQcm9ibGVtIA0KQWx0aG91 Z2ggdGVsZXByZXNlbmNlIHN5c3RlbXMgYXJlIGJhc2VkIG9uIG9wZW4gc3RhbmRhcmRzIHN1Y2gg YXMgUlRQLCANClNJUCwgSC4yNjQsIEguMzIzIHN1aXRlLCB0aGV5IGNhbm5vdCBlYXNpbHkgaW50 ZXJvcGVyYXRlIHdpdGggZWFjaCBvdGhlciANCndpdGhvdXQgb3BlcmF0b3IgYXNzaXN0YW5jZSBh bmQgZXhwZW5zaXZlIGFkZGl0aW9uYWwgZXF1aXBtZW50IHRoYXQgDQp0cmFuc2xhdGVzIGZyb20g b25lIHZlbmRvciB0byBhbm90aGVyLiBJdCB3b3VsZCBiZSBsaWtlIGhhdmluZyB0byBtYWtlIA0K c3VyZSBhbGwgcGFydGllcyBhcmUgb24gdGhlIHNhbWUgZXF1aXBtZW50IChhbmQgbmV0d29yaykg d2hlbiBtYWtpbmcgYSANCnRlbGVwaG9uZSBjYWxsLiAgQSBtYWpvciBmYWN0b3IgaW4gdGhlIGlu YWJpbGl0eSBvZiBUZWxlcHJlc2VuY2Ugc3lzdGVtcyANCnRvIHdvcmsgd2l0aCBlYWNoIG90aGVy IGlzIHRoYXQgdGhlcmUgaXMgbm8gc3RhbmRhcmQgZGVzY3JpcHRpb24gb2YgdGhlIA0KbXVsdGlw bGUgc3RyZWFtcyB0aGF0IGNvbXByaXNlIHRoZSBtZWRpYSBmbG93cy4gDQogIA0KRm9yIGV4YW1w bGUsIGluIGEgbXVsdGlwbGUgc2NyZWVuIGNvbmZlcmVuY2UsIHRoZSB2aWRlbyBhbmQgYXVkaW8g c3RyZWFtcyANCnNlbnQgZnJvbSByZW1vdGUgcGFydGljaXBhbnRzIG11c3QgYmUgdW5kZXJzdG9v ZCBieSByZWNlaXZlcnMgc28gdGhhdCB0aGV5IA0KY2FuIGJlIHByZXNlbnRlZCBpbiBhIGNvaGVy ZW50IGFuZCBsaWZlLWxpa2UgbWFubmVyLiBUaGlzIGluY2x1ZGVzIHRoZSANCmFiaWxpdHkgdG8g cHJlc2VudCB0aGUgcmVtb3RlIHBhcnRpY2lwYW50cyBhdCB0aGVpciB0cnVlIHNpemUgZm9yIHRo ZWlyIA0KYXBwYXJlbnQgZGlzdGFuY2UsIHdoaWxlIG1haW50YWluaW5nIGNvcnJlY3QgZXllIGNv bnRhY3QsIGdlc3RpY3VsYXIgY3VlcywgDQphbmQgc2ltdWx0YW5lb3VzbHkgcHJvdmlkaW5nIGEg c3BhdGlhbCBhdWRpbyBzb3VuZCBzdGFnZSBjb25zaXN0ZW50IHdpdGggDQp0aGUgdmlkZW8gcHJl c2VudGF0aW9uLiAgVGhlIHJlY2VpdmluZyBkZXZpY2UgdGhhdCBkZWNpZGVzIGhvdyB0byBkaXNw bGF5IA0KdGhlIGluY29taW5nIGluZm9ybWF0aW9uIG5lZWRzIHRvIHVuZGVyc3RhbmQgYSBudW1i ZXIgb2YgdmFyaWFibGVzIHN1Y2ggYXMgDQp0aGUgc3BhdGlhbCBwb3NpdGlvbiBvZiB0aGUgc3Bl YWtlciwgdGhlIGZpZWxkIG9mIHZpZXcgb2YgdGhlIGNhbWVyYXMsIHRoZSANCmNhbWVyYSB6b29t LCB3aGljaCBtZWRpYSBzdHJlYW0gaXMgcmVsYXRlZCB0byBlYWNoIG9mIHRoZSBkaXNwbGF5cywg ZXRjLiANCiAgDQpDaGFydGVyIA0KVGhlIFRlbGVwcmVzZW5jZSBNdWx0aS1TdHJlYW1zIHdvcmsg aXRlbSBpbiBESVNQQVRDSCBpcyBjaGFydGVyZWQgdG8gDQpkZWZpbmUgYW5kIHNwZWNpZnkgdGhl IGNvbnRlbnQgb2YgbWVkaWEgbXVsdGktc3RyZWFtIG1lc3NhZ2VzIGFuZCB0aGUgd2F5IA0KdGhl c2Ugd2lsbCBiZSB0cmFuc3BvcnRlZC4gDQpUaGlzIHdvcmsgaXMgYWltZWQgYXQgcHJvdmlkaW5n IGEgc3RhbmRhcmQgZm9yIHRoZSBleGNoYW5nZSBvZiBtZWRpYSANCnNlbWFudGljcyBpbmZvcm1h dGlvbiB0aGF0IHdpbGwgZm9zdGVyIGludGVyb3BlcmFibGUgZW5kIHN0YXRpb25zIGFuZCANCmNv bmZlcmVuY2UgYnJpZGdlcy4gVGhpcyB3b3JrIGl0ZW0gd2lsbCBzcGVjaWZ5IHRoZSB2YXJpYWJs ZXMgdGhhdCANCmRlc2NyaWJlIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIG1lZGlhIHN0cmVhbXMgYW5k IHRoZSByZWNvbW1lbmRlZCBiZWhhdmlvciANCnRvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eS4g ICANCiAgDQpUaGlzIHJlcXVpcmVzIGNvbnNpZGVyaW5nIGN1cnJlbnQgd2lkZWx5IGRlcGxveWVk IHVzZSBjYXNlcywgc3VjaCBhcyANCnNpbmdsZSBhbmQgbXVsdGlwbGUgc2NyZWVucywgbXVsdGkt cG9pbnQsIFNjYWxhYmxlIFZpZGVvIENvZGluZyAoU1ZDKSwgYXMgDQp3ZWxsIGFzIGNhc2VzIHRo YXQgYXJlIGV4cGVjdGVkIHRvIGJlIGltcGxlbWVudGVkIHVzaW5nIHRoZSBwcm90b2NvbCANCmZy YW1ld29yayBwcm9kdWNlZCBieSB0aGlzIHdvcmsgaXRlbS4gIFRoZSBtZXRob2RvbG9neSBmb3Ig ZGVzY3JpYmluZyB0aGUgDQp2YXJpYWJsZXMgbXVzdCBhbGxvdyBleHRlbnNpYmlsaXR5IG9mIHRo ZSB2YXJpYWJsZXMsIHNpbmNlIHRlbGVwcmVzZW5jZSBpcyANCnN0aWxsIGEgeW91bmcgdGVjaG5v bG9neSBhbmQgbWF5IGhhdmUgdXNlIGNhc2VzIHRoYXQgYXJlIG5vdCBjdXJyZW50bHkgDQpjb25z aWRlcmVkLiANCiAgDQpUaGUgd29yayBpdGVtIHdpbGwgaWRlbnRpZnkgdXNlIGNhc2VzLCBkZWZp bmUgcmVxdWlyZW1lbnRzLCBhbmQgZGVmaW5lIGEgDQptZXRob2QgZm9yIGRlc2NyaWJpbmcgYW5k IHRyYW5zcG9ydGluZyBpbmZvcm1hdGlvbiBhYm91dCBtdWx0aXBsZSBtZWRpYSANCnN0cmVhbXMs IGluY2x1ZGluZyBhIHNwZWNpZmljYXRpb24gb2YgdmFyaWFibGVzIHJlcXVpcmVkIHRvIHN1cHBv cnQgdGhlIA0KdXNlIGNhc2VzLiBUaGlzIHdvcmsgaXRlbSB3aWxsIGNvbnNpZGVyIHRoZSByZXVz ZSBvZiBleGlzdGluZyBJRVRGIA0KcHJvdG9jb2xzIGFuZCBwcm9kdWNlIGFuIGFyY2hpdGVjdHVy ZS9wcm90b2NvbCBmcmFtZXdvcmsgZG9jdW1lbnQgDQpkZXNjcmliaW5nIHRoZSBwcm90b2NvbHMg cmVxdWlyZWQgdG8gYmUgaW1wbGVtZW50ZWQgdG8gc3VwcG9ydCB0aGlzIA0KZnVuY3Rpb25hbGl0 eS4gIFRoZSBkb2N1bWVudCB3aWxsIGlkZW50aWZ5IGFueSBlbmhhbmNlbWVudHMgcmVxdWlyZWQg dG8gDQpleGlzdGluZyBwcm90b2NvbHMgYXMgd2VsbCBhcyBkZXNjcmliaW5nIG5ldyBwcm90b2Nv bChzKSBmb3IgaW50ZXJvcGVyYWJsZSANCm11bHRpLXN0cmVhbXMgbmVnb3RpYXRpb24gdGhhdCBt YXkgYmUgcmVxdWlyZWQuIA0KICANClNjb3BlIA0KVGhlIHNjb3BlIGluY2x1ZGVzIGJvdGggc3lz dGVtcyB0aGF0IHByb3ZpZGUgYSBmdWxseSBpbW1lcnNpdmUgZXhwZXJpZW5jZSwgDQphbmQgc3lz dGVtcyB0aGF0IGludGVyd29yayB3aXRoIHRoZW0gYW5kIHRoZXJlZm9yZSBuZWVkIHRvIHVuZGVy c3RhbmQgdGhlIA0Kc2FtZSBtdWx0aXBsZSBzdHJlYW0gc2VtYW50aWNzLiANCiAgDQpUaGUgZm9j dXMgb2YgdGhpcyB3b3JrIGlzIG9uIGF1ZGlvIGFuZCB2aWRlbyBtdWx0aXBsZSBzdHJlYW1zLCBo b3dldmVyIA0Kb3RoZXIgbWVkaWEgdHlwZXMgbWF5IGJlIGNvbnNpZGVyZWQuICBEZWZpbml0aW9u IG9mIG5ldyBhcHBsaWNhdGlvbiANCnByb3RvY29scyBpcyBub3Qgd2l0aGluIHRoZSBzY29wZSBv ZiB0aGlzIHdvcmsgDQogIA0KW0lzIHRoZXJlIGFueXRoaW5nIGVsc2Ugd2UgbmVlZCB0byBleHBs aWNpdGx5IHNheSBpcyBvdXQgb2Ygc2NvcGU/XSANCiAgDQpUaGUgZ3JvdXAgd2lsbCBwcm9kdWNl IA0KLSBSZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcyANCiAgDQotIEFyY2hpdGVjdHVyYWwgRnJh bWV3b3JrIGRlc2NyaWJpbmcgdGhlIHByb3RvY29scyByZXF1aXJlZCB0byBiZSANCmltcGxlbWVu dGVkIHRvIHN1cHBvcnQgdGhpcyBmdW5jdGlvbmFsaXR5IGFuZCBpZGVudGlmeWluZyBleGlzdGlu ZyANCnByb3RvY29sIGVuaGFuY2VtZW50cyBhbmQgbmV3IHByb3RvY29sIGZ1bmN0aW9uYWxpdHkg cmVxdWlyZWQgDQogIA0KLSBTcGVjaWZpY2F0aW9uIG9mIGEgbmV3IHByb3RvY29sIHRvIHN1cHBv cnQgdGVsZXByZXNlbmNlIG11bHRpLXN0cmVhbXMgDQpbaWYgcmVxdWlyZWRdIA0KICANCkdvYWxz IGFuZCBNaWxlc3RvbmVzIA0KDQpOb3YgMjAxMCANClVzZSBDYXNlcyBhbmQgUmVxdWlyZW1lbnRz IHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbCBSRkMgDQpNYXJjaCAyMDExIA0KQXJjaGl0ZWN0dXJl IHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbCBSRkMgDQpNYXJjaCAyMDExIA0KUmV2aXNlIENoYXJ0 ZXIgW0lGIG5ldyBwcm90b2NvbCBpcyBub3QgcmVxdWlyZWRdIA0KTm92IDIwMTEgDQpTdWJtaXQg cHJvdG9jb2wgZHJhZnQgdG8gSUVTRyBhcyBQcm9wb3NlZCBTdGFuZGFyZCBSRkMgDQoNCiAgDQog IA0KICANCiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KDQogDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMg DQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls IGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVk IHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9y IG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0u DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kg YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNv bW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3Nl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRo aXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3Bh bSBzeXN0ZW0uDQo= --=_alternative 0006548B48257737_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsbHluLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U3VyZS4gV2UgY2FuIGRvIHRo ZSBzcGxpdGluZyBldmFsdWF0aW9uDQpsYXRlciBhcyB5b3Ugc2FpZC48L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNoZWVycyw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7 ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4N CiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjxiPiZxdW90O0FsbHluIFJvbWFub3cgKGFsbHluKSZxdW90Ow0KJmx0O2FsbHlu QGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDEwLTA2LTAzIDAwOjE1PC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZsdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZndDs8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZxdW90O0lFVEYgRElTUEFUQ0ggbGlzdCZxdW90OyAmbHQ7ZGlzcGF0Y2hA aWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW2Rpc3BhdGNoXSBNdWx0aS1zdHJl YW1zIGZvciB0ZWxlcHJlc2VuY2UNCmRlc2NyaXB0aW9uIG9mIHdvcms8L2ZvbnQ+PC90YWJsZT4N Cjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+ PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNl PSJzYW5zLXNlcmlmIj5IaSBHYW8sPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s b3I9IzAwNDA4MCBmYWNlPSJzYW5zLXNlcmlmIj5JIGhhZCBhIGNoYW5jZSB0byB0YWxrDQp3aXRo IE1hcnkgYWJvdXQgeW91ciBpZGVhIHRvIHNwbGl0IHVwIHRoZSB3b3JrLCBhbmQgc2hlIGNvbmZp cm1lZCB0aGF0DQppdCBpcyBnb29kIHByYWN0aWNlIGluIGdlbmVyYWwgdG8gZG8gc28sIGJ1dCB3 ZSB0aG91Z2h0IGl0IGlzIGFzIHlldCB0b28NCmVhcmx5IHRvIHNwbGl0IHVwIHRoZSBtdWx0aS1z dHJlYW0gd29yay4gJm5ic3A7QXMgd2UgcHJvZ3Jlc3Mgd2l0aCB1c2UNCmNhc2VzLCBwcm9ibGVt IHN0YXRlbWVudCBhbmQgcmVxdWlyZW1lbnRzLCB3ZSB3aWxsIGJlIGFibGUgdG8gc2VlIGJldHRl cg0KaWYgdGhlIHRvcGljIHNob3VsZCBiZSBzcGxpdCB1cC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgcmVnYXJkcyw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0ic2Fucy1zZXJpZiI+ QWxseW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZy b206PC9iPiBnYW8ueWFuZzJAenRlLmNvbS5jbiBbbWFpbHRvOmdhby55YW5nMkB6dGUuY29tLmNu XQ0KPGI+PGJyPg0KU2VudDo8L2I+IFR1ZXNkYXksIE1heSAxOCwgMjAxMCAxMDozMyBQTTxiPjxi cj4NClRvOjwvYj4gQWxseW4gUm9tYW5vdyAoYWxseW4pPGI+PGJyPg0KQ2M6PC9iPiBJRVRGIERJ U1BBVENIIGxpc3Q8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gTXVsdGktc3Ry ZWFtcyBmb3IgdGVsZXByZXNlbmNlIGRlc2NyaXB0aW9uDQpvZiB3b3JrPC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpIaSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpJIGhh dmUgdHdvIGxldmVsIG9mIGNvbW1lbnRzLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCjEuIEZl ZWxpbmcgZm9yIHRoZSB0b3BpYzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRlY2huaWNhbGx5LCBJIGFt IHF1aXQgZ2xhZCB0byBzZWUgc3VjaCBkaXNjdXNzaW9uIGFib3V0IHRlbGVwcmVzZW5jZSwNCndo aWNoIGlzIHRyYWlsYmxhemVyIGZvciBWUihWaXJ0dWFsIFJlYWxpdHkpIHByb2R1Y3Rpb24uIDwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KMi4gQWJvdXQgdGhlIGNoYXJ0ZXIgV0c8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj48YnI+DQpPbmUgcmV2b2x1dGlvbmFyeSBhcHBsaWNhdGlvbiwgc3VjaCB0ZWxlcHJlc2Vu Y2UsIHdvdWxkIGNvdmVyIGJhc2ljIHByb3RvY29sDQpsZXZlbCwgYXBwbGljYXRpb24gY29udHJv bCBsZXZlbCwgYW5kIGludGVyd29ya2luZyBpc3N1ZS4gPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQpJZiB0aGUgd29yayBpcyBqdXN0IGZvY3VzZWQgb24gcHVyZSBpbnRlcndvcmtpbmcgaXNzdWUs IHRoZW4gdGhlIHRvcGljcw0KY2FuIGJlIGRpdmlkZWQgaW50byBzbWFsbGVyIG9uZSwgd2hpY2gg bWlnaHQgYmUgaW4gb3RoZXIgYmFzaWMgcHJvdG9jb2xzJw0KV0cncyBzY29wZS4gQnV0IGlmIHRo ZSBhcHBsaWNhdGlvbiBpdHNlbGYgaXMgbmV3LCBhbmQgaGFzIHNvbWUgbmV3IGNoYXJhY3Rlcmlz dGljLA0KbW9yZSB3b3JrIHNob3VsZCBiZSBwcm9wb3NlZC4gPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 YnI+DQpJZiB0aGUgd29yayBpcyBhbHNvIGZvY3VzZWQgb24gdGVsZXByZXNlbmNlIGFwcGxpY2F0 aW9uLCB3aGljaCBpcyBhIGNvbmZlcmVuY2luZw0Kc3lzdGVtLCB0aGUgeGNvbiBXRyBtaWdodCBi ZSBwcm9wZXIgb25lIGZvciBhcHBsaWNhdGlvbiBsZXZlbCBkZWZpbml0aW9uLjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48YnI+DQpJZiB0aGUgY2hhcnRlciBhbHNvIHdhbnQgdG8gdGFsayB0aGUgZXNl bnRpYWwgYXNwZWN0IG9mIHRlbGVwcmVzZW5jZShvcg0KbW9yZSBhYnN0cmFjdGx5LCBhYm91dCBW UiksIHN1Y2ggYXMgaG93IHRvIHVzaW5nIFNEUCwgb3IgcmVsYXRpdmUgcHJvdG9jb2wNCnRvIGRl c2NyaWJlIHRoZSBzdHJlYW1zIGFuZCBpdCdzIGNvbGxhYm9yYXRpb24sIGl0IHdvdWxkIGJlIHF1 aXRlIG5ldyB0b3BpYy4NCk9uZSBuZXcgV0cgbWlnaHQgYmUgYmV0dGVyLjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCkkgZmluZCB0aGUgY2hhcnRlciBzZWVtcyBjb3ZlcnMgYWxsIHRo ZSB0aHJlZSB0aGluZy4gU28sIEkgc3VnZ2VzdCB5b3UNCmNsYXNzaWZ5IHN1Y2ggZGlmZmVyZW50 IGxldmVsIHJlcXVpcmVtZW50LiBUaGVuLCB3ZSBtYXkgZmluZCB3aGljaCBwYXJ0DQppcyBwcm9w ZXIgZm9yIHdoaWNoIFdHLCBhbmQgd2hpY2ggcGFydCBzaG91bGQgYmUgY292ZXJlZCBieSBuZXcg V0cuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoYW5rcyw8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQpHYW88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4NClppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQpUZWwg Jm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQpUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjEx PGJyPg0KZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9NDIlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+JnF1b3Q7QWxseW4g Um9tYW5vdyAoYWxseW4pJnF1b3Q7DQombHQ7YWxseW5AY2lzY28uY29tJmd0OzwvYj4gPC9mb250 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQq3orz+yMs8L2ZvbnQ+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj46ICZuYnNwO2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9IkFyaWFsIj4yMDEwLTA1LTE5IDAyOjMwPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD01NyU+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTEwJT4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZCB3aWR0aD04OSU+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mcXVvdDtJRVRGIERJU1BBVENI IGxpc3QmcXVvdDsNCiZsdDtkaXNwYXRjaEBpZXRmLm9yZyZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9IkFyaWFsIj5bZGlzcGF0Y2hdIE11bHRpLXN0cmVhbXMgZm9yIHRlbGVwcmVzZW5j ZQ0KZGVzY3JpcHRpb24gb2Ygd29yazwvZm9udD48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8cD4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3Rh YmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkhpIEZvbGtz LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCk1hbnkgb2Yg eW91IGFyZSBhd2FyZSBvZiB0ZWxlcHJlc2VuY2Ugc3lzdGVtcyAodmlkZW8gY29uZmVyZW5jaW5n IG9uIHN0ZXJvaWRzLi46KSwNCmZld2VyIHByb2JhYmx5IGFyZSBhd2FyZSBvZiB0aGUgZmFjdCB0 aGF0IHRoZSBjdXJyZW50IHN5c3RlbXMgYXJlIG5vdCBpbnRlcm9wZXJhYmxlDQp3aXRoIGVhY2gg b3RoZXIuIEFmdGVyIHRhbGtpbmcgd2l0aCBNYXJ5IGFuZCBDdWxsZW4sIHdlIGhhdmUgYSByb3Vn aCBkcmFmdA0Kb2YgYSBjaGFydGVyIHRvIHdvcmsgb24gdGhpcyBwcm9ibGVtIGluIERJU1BBVENI LCAmbmJzcDtmb3IgZGlzY3Vzc2lvbg0Kb24gdGhlIG1haWxpbmcgbGlzdC48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpXZSBkb26hr3QgeWV0IGtub3cgd2hl dGhlciBhIHdvcmtpbmcgZ3JvdXAgd291bGQgbmVlZCB0byBiZSBzcHVuIG91dCBvcg0Kbm90IKhD IHRoYXQgd2lsbCBiZSBjbGFyaWZpZWQgYXMgd2UgZ28uPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCldlIHRoaW5rIHRoZXJlIGlzIGVub3VnaCBiYWNrZ3Jv dW5kIGluZm8gaW4gdGhlIHdvcmsgZGVzY3JpcHRpb24gdG8gc3RhcnQNCmEgZGlzY3Vzc2lvbiwg YW5kIHBsYW4gdG8gc2VuZCBvdXQgdXNlIGNhc2VzIGZvciBkaXNjdXNzaW9uIHNob3J0bHkuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCldobyBpcyB0aGUg d2U/IFNldmVyYWwgbWFrZXJzIGFuZCBwcm92aWRlcnMgb2YgdGVsZXByZXNlbmNlIHN5c3RlbXMg aGF2ZQ0KZ290dGVuIHRvZ2V0aGVyIHRvIGRlZmluZSB0aGUgbWFpbiBwcm9ibGVtIGluIGludGVy b3BlcmFiaWxpdHkgqEMgdGhlDQpoYW5kbGluZyBvZiBtdWx0aS1zdHJlYW1zLjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoYW5rcyBmb3IgeW91ciB0aG91 Z2h0cy08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpBbGx5bjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOzwvZm9udD4NCjxkaXYgYWxpZ249Y2VudGVyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGI+PGJyPg0KTXVsdGktc3RyZWFtcyBmb3IgVGVsZXByZXNlbmNlIERlc2Ny aXB0aW9uIG9mIFdvcms8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPjxicj4NCiA8L2I+PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48Yj48YnI+DQogPC9iPjwvZm9udD48L2Rpdj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxiPjxicj4NCiA8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48Yj48YnI+DQpC YWNrZ3JvdW5kPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCk9uZSBicmFuY2ggb2YgdmlkZW8gY29u ZmVyZW5jaW5nIGhhcyBldm9sdmVkIHRoYXQgaXMgZm9jdXNlZCBvbiBpbW1lcnNpdmUNCqGwYmVp bmcgdGhlcmWhsSBleHBlcmllbmNlLiAmbmJzcDtSZWZlcnJlZCB0byBpbiB2YXJpb3VzIHdheXMg c3VjaCBhcw0KdmlydHVhbCBjb25mZXJlbmNpbmcsIHRlbGVwcmVzZW5jZSBvciBtZWRpYSBzcGFj ZXMsIGVhcmx5IHN5c3RlbXMgd2VyZQ0KbWFpbmx5IHJlc2VhcmNoIHByb2plY3RzIG9yIGJ1c2lu ZXNzIHN5c3RlbXMgd2l0aCBsaW1pdGVkIGRlcGxveW1lbnRzLg0KJm5ic3A7SW4gcmVjZW50IHll YXJzIHRlbGVwcmVzZW5jZSBzeXN0ZW1zIGhhdmUgc2VlbiBjb25zaWRlcmFibGUgbWFya2V0DQpz dWNjZXNzLiAmbmJzcDtGb2xsb3dpbmcgdGhlIG1vZGVsIG9mIGVhcmx5IHN5c3RlbXMsIHRoZSBm aXJzdCB3YXZlIG9mDQpjb21tZXJjaWFsIHN5c3RlbXMgaGF2ZSBiZWVuIHR5cGljYWxseSBsb2Nh dGVkIGluIHNwZWNpYWxseSBkZXNpZ25lZCBzaW5nbGUtcHVycG9zZQ0Kcm9vbXMgd2l0aCBtdWx0 aXBsZSByZWxhdGl2ZWx5IGxhcmdlIGRpc3BsYXlzIHBlcm1pdHRpbmcgbGlmZSBzaXplIGltYWdl DQpyZXByb2R1Y3Rpb24sIG11bHRpcGxlIGNhbWVyYXMsIGVuY29kZXJzLCBkZWNvZGVycyBhbmQg bWljcm9waG9uZXMuICZuYnNwO1RoZXNlDQpzeXN0ZW1zIGhhdmUgc2V2ZXJhbCBpbXBvcnRhbnQg Y2hhcmFjdGVyaXN0aWNzIHRoYXQgYXJlIGRpZmZlcmVudCBmcm9tDQptb3JlIHRyYWRpdGlvbmFs IHZpZGVvIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIGZpcnN0IGRpZmZlcmVuY2UgY29uY2VybnMg Y29udHJvbGxpbmcgdGhlIHZpc3VhbCB2aWV3cG9pbnQgaW4gb3JkZXINCnRvIGltcHJvdmUgcGFy dGljaXBhbnQgbm9udmVyYmFsIGNvbW11bmljYXRpb24uIFRoZXNlIHN5c3RlbXMgcHJlc2VydmUN CmVzc2VudGlhbCBncm91cCBtZWV0aW5nIGNoYXJhY3RlcmlzdGljcyBzdWNoIGFzIGV5ZSBjb250 YWN0LCBncm91cCBnZXN0dXJlcywNCnNlYXRpbmcgb3JkZXIgYW5kIHNwYXRpYWwgYXVkaW8gYnkg Y2FyZWZ1bGx5IG9yY2hlc3RyYXRpbmcgdGhlIG1pa2luZyBhbmQNCmNhbWVyYSBhbmdsZXMgYXQg ZWFjaCBvZiB0aGUgc2l0ZXMgLiBUaGlzIGlzIGRpc3RpbmN0IGZyb20gdGhlIG1vcmUgdHJhZGl0 aW9uYWwNCmFwcHJvYWNoIHdoZXJlIHRoZSBnZW9tZXRyaWMgcmVsYXRpb25zaGlwIGJldHdlZW4g bWVkaWEgc3RyZWFtcyBpcyBub3QNCnVzZWQgdG8gcHJlc2VydmUgaW50ZXItc3RyZWFtIGNvbW11 bmljYXRpb24gYXNwZWN0cyBzdWNoIGFzIGV5ZSBjb250YWN0DQphbmQgZ3JvdXAgZHluYW1pY3Mu ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkEg c2Vjb25kIGRpZmZlcmVuY2UgaXMgbWFuaXB1bGF0aW9uIG9mIHRoZSBlbnZpcm9ubWVudCB0byBp bXByb3ZlIGltbWVyc2lvbi4NCiZuYnNwO1dpdGggdGVsZXByZXNlbmNlIHN5c3RlbXMsIGNpbmVt YXRvZ3JhcGhpYyBhc3BlY3RzIG9mIHRoZSBsb2NhbCBlbnZpcm9ubWVudA0KcmVwcm9kdWN0aW9u IGFyZSBjYXJlZnVsbHkgcGxhbm5lZCBpbmNsdWRpbmcgY29sb3IsIHRhYmxlIHNoYXBlLCBzZWF0 aW5nDQphbmQgbGlnaHRpbmcgc28gdGhhdCB3aGVuIGNvbWJpbmVkIHdpdGggbGFyZ2UgaGlnaCBx dWFsaXR5IGRpc3BsYXlzLCBhDQpzdHJvbmcgc2Vuc2Ugb2YgYSAmcXVvdDt0cm9tcGUgbCdvZWls JnF1b3Q7IG9yICZxdW90O2JlaW5nIHRoZXJlJnF1b3Q7DQppbW1lcnNpdmUgZXhwZXJpZW5jZSBp cyBjcmVhdGVkLiAmbmJzcDtUeXBpY2FsIHZpZGVvIGNvbmZlcmVuY2Ugc3lzdGVtcw0KZG8gbm90 IGluY2x1ZGUgdGhlc2UgY29uc2lkZXJhdGlvbnMuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQXJpYWwiPjxicj4NCkFzIHRlbGVwcmVzZW5jZSB2aWRlbyBzeXN0ZW1zIGhhdmUg YmVjb21lIHN1Y2Nlc3NmdWwgaW4gdGhlIG1hcmtldCwgbWFudWZhY3R1cmVycw0KaGF2ZSBzdGFy dGVkIGV4cGxvcmluZyBkZWxpdmVyeSBvZiB0aGUgbm9udmVyYmFsIGNvbW11bmljYXRpb24gYW5k IGltbWVyc2l2ZQ0KdmFsdWVzIG9mIHRlbGVwcmVzZW5jZSB2aWEgc21hbGxlciwgbGVzcyBleHBl bnNpdmUgYW5kIG1vcmUgZmxleGlibGUgdmlkZW8NCmNvbmZlcmVuY2luZyBzeXN0ZW1zIGZvciBh IHZhcmlldHkgb2YgdmVudWVzLCBzdWNoIGFzIGluZGl2aWR1YWwgb2ZmaWNlcywNCmhvbWVzIGFu ZCBraW9za3MuIFRoZXNlIGFyZSBhbHNvICZuYnNwO3RlbGVwcmVzZW5jZSBzeXN0ZW1zLCBzaW5j ZSB0aGUNCmF1ZGlvIGFuZCB2aWRlbyBxdWFsaXR5IGlzIGhpZ2ggZW5vdWdoIHRvIGFsbG93IGNs ZWFyIGltYWdlIHJlcHJvZHVjdGlvbg0KZm9yIG5vbnZlcmJhbCBjb21tdW5pY2F0aW9uLCB0aGV5 IGFyZSBhYmxlIHRvIHNlbmQgYW5kIHJlY2VpdmUgbXVsdGlwbGUNCm1lZGlhIHN0cmVhbXMsIGFu ZCBsYXJnZSBjb29yZGluYXRlZCBtdWx0aSBpbWFnZSBkaXNwbGF5cyBhcmUgYXZhaWxhYmxlDQpm b3IgaW1tZXJzaXZlIGluc3RhbGxhdGlvbnMuICZuYnNwOyBBcyB0aGUgaW5kdXN0cnkgZGV2ZWxv cHMsIHRoZSBsaW5lDQpiZXR3ZWVuIHRlbGVwcmVzZW5jZSBhbmQgdmlkZW8gY29uZmVyZW5jaW5n IG1heSBiZWNvbWUgYmx1cnJlZCBhcyBub252ZXJiYWwNCmNvbW11bmljYXRpb24gYW5kIGltbWVy c2l2ZSBpbnN0YWxsYXRpb25zIGJlY29tZSBicm9hZGx5IGF2YWlsYWJsZS48L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGI+PGJyPg0KUHJvYmxlbTwvYj48L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkFyaWFsIj48YnI+DQpBbHRob3VnaCB0ZWxlcHJlc2VuY2Ugc3lzdGVtcyBhcmUgYmFzZWQgb24g b3BlbiBzdGFuZGFyZHMgc3VjaCBhcyBSVFAsDQpTSVAsIEguMjY0LCBILjMyMyBzdWl0ZSwgdGhl eSBjYW5ub3QgZWFzaWx5IGludGVyb3BlcmF0ZSB3aXRoIGVhY2ggb3RoZXINCndpdGhvdXQgb3Bl cmF0b3IgYXNzaXN0YW5jZSBhbmQgZXhwZW5zaXZlIGFkZGl0aW9uYWwgZXF1aXBtZW50IHRoYXQg dHJhbnNsYXRlcw0KZnJvbSBvbmUgdmVuZG9yIHRvIGFub3RoZXIuIEl0IHdvdWxkIGJlIGxpa2Ug aGF2aW5nIHRvIG1ha2Ugc3VyZSBhbGwgcGFydGllcw0KYXJlIG9uIHRoZSBzYW1lIGVxdWlwbWVu dCAoYW5kIG5ldHdvcmspIHdoZW4gbWFraW5nIGEgdGVsZXBob25lIGNhbGwuICZuYnNwO0ENCm1h am9yIGZhY3RvciBpbiB0aGUgaW5hYmlsaXR5IG9mIFRlbGVwcmVzZW5jZSBzeXN0ZW1zIHRvIHdv cmsgd2l0aCBlYWNoDQpvdGhlciBpcyB0aGF0IHRoZXJlIGlzIG5vIHN0YW5kYXJkIGRlc2NyaXB0 aW9uIG9mIHRoZSBtdWx0aXBsZSBzdHJlYW1zDQp0aGF0IGNvbXByaXNlIHRoZSBtZWRpYSBmbG93 cy4gPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KRm9yIGV4YW1wbGUsIGluIGEgbXVs dGlwbGUgc2NyZWVuIGNvbmZlcmVuY2UsIHRoZSB2aWRlbyBhbmQgYXVkaW8gc3RyZWFtcw0Kc2Vu dCBmcm9tIHJlbW90ZSBwYXJ0aWNpcGFudHMgbXVzdCBiZSB1bmRlcnN0b29kIGJ5IHJlY2VpdmVy cyBzbyB0aGF0IHRoZXkNCmNhbiBiZSBwcmVzZW50ZWQgaW4gYSBjb2hlcmVudCBhbmQgbGlmZS1s aWtlIG1hbm5lci4gVGhpcyBpbmNsdWRlcyB0aGUNCmFiaWxpdHkgdG8gcHJlc2VudCB0aGUgcmVt b3RlIHBhcnRpY2lwYW50cyBhdCB0aGVpciB0cnVlIHNpemUgZm9yIHRoZWlyDQphcHBhcmVudCBk aXN0YW5jZSwgd2hpbGUgbWFpbnRhaW5pbmcgY29ycmVjdCBleWUgY29udGFjdCwgZ2VzdGljdWxh ciBjdWVzLA0KYW5kIHNpbXVsdGFuZW91c2x5IHByb3ZpZGluZyBhIHNwYXRpYWwgYXVkaW8gc291 bmQgc3RhZ2UgY29uc2lzdGVudCB3aXRoDQp0aGUgdmlkZW8gcHJlc2VudGF0aW9uLiAmbmJzcDtU aGUgcmVjZWl2aW5nIGRldmljZSB0aGF0IGRlY2lkZXMgaG93IHRvDQpkaXNwbGF5IHRoZSBpbmNv bWluZyBpbmZvcm1hdGlvbiBuZWVkcyB0byB1bmRlcnN0YW5kIGEgbnVtYmVyIG9mIHZhcmlhYmxl cw0Kc3VjaCBhcyB0aGUgc3BhdGlhbCBwb3NpdGlvbiBvZiB0aGUgc3BlYWtlciwgdGhlIGZpZWxk IG9mIHZpZXcgb2YgdGhlIGNhbWVyYXMsDQp0aGUgY2FtZXJhIHpvb20sIHdoaWNoIG1lZGlhIHN0 cmVhbSBpcyByZWxhdGVkIHRvIGVhY2ggb2YgdGhlIGRpc3BsYXlzLA0KZXRjLiA8YnI+DQogPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkFyaWFsIj48Yj48YnI+DQpDaGFydGVyPC9iPjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N ClRoZSBUZWxlcHJlc2VuY2UgTXVsdGktU3RyZWFtcyB3b3JrIGl0ZW0gaW4gRElTUEFUQ0ggaXMg Y2hhcnRlcmVkIHRvIGRlZmluZQ0KYW5kIHNwZWNpZnkgdGhlIGNvbnRlbnQgb2YgbWVkaWEgbXVs dGktc3RyZWFtIG1lc3NhZ2VzIGFuZCB0aGUgd2F5IHRoZXNlDQp3aWxsIGJlIHRyYW5zcG9ydGVk LiA8YnI+DQpUaGlzIHdvcmsgaXMgYWltZWQgYXQgcHJvdmlkaW5nIGEgc3RhbmRhcmQgZm9yIHRo ZSBleGNoYW5nZSBvZiBtZWRpYSBzZW1hbnRpY3MNCmluZm9ybWF0aW9uIHRoYXQgd2lsbCBmb3N0 ZXIgaW50ZXJvcGVyYWJsZSBlbmQgc3RhdGlvbnMgYW5kIGNvbmZlcmVuY2UNCmJyaWRnZXMuIFRo aXMgd29yayBpdGVtIHdpbGwgc3BlY2lmeSB0aGUgdmFyaWFibGVzIHRoYXQgZGVzY3JpYmUgdGhl IHNlbWFudGljcw0Kb2YgdGhlIG1lZGlhIHN0cmVhbXMgYW5kIHRoZSByZWNvbW1lbmRlZCBiZWhh dmlvciB0byBhY2hpZXZlIGludGVyb3BlcmFiaWxpdHkuDQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48 YnI+DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpUaGlzIHJlcXVpcmVzIGNvbnNpZGVyaW5n IGN1cnJlbnQgd2lkZWx5IGRlcGxveWVkIHVzZSBjYXNlcywgc3VjaCBhcyBzaW5nbGUNCmFuZCBt dWx0aXBsZSBzY3JlZW5zLCBtdWx0aS1wb2ludCwgU2NhbGFibGUgVmlkZW8gQ29kaW5nIChTVkMp LCBhcyB3ZWxsDQphcyBjYXNlcyB0aGF0IGFyZSBleHBlY3RlZCB0byBiZSBpbXBsZW1lbnRlZCB1 c2luZyB0aGUgcHJvdG9jb2wgZnJhbWV3b3JrDQpwcm9kdWNlZCBieSB0aGlzIHdvcmsgaXRlbS4g Jm5ic3A7VGhlIG1ldGhvZG9sb2d5IGZvciBkZXNjcmliaW5nIHRoZSB2YXJpYWJsZXMNCm11c3Qg YWxsb3cgZXh0ZW5zaWJpbGl0eSBvZiB0aGUgdmFyaWFibGVzLCBzaW5jZSB0ZWxlcHJlc2VuY2Ug aXMgc3RpbGwNCmEgeW91bmcgdGVjaG5vbG9neSBhbmQgbWF5IGhhdmUgdXNlIGNhc2VzIHRoYXQg YXJlIG5vdCBjdXJyZW50bHkgY29uc2lkZXJlZC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KIDwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIHdvcmsgaXRlbSB3aWxsIGlkZW50aWZ5IHVzZSBjYXNl cywgZGVmaW5lIHJlcXVpcmVtZW50cywgYW5kIGRlZmluZQ0KYSBtZXRob2QgZm9yIGRlc2NyaWJp bmcgYW5kIHRyYW5zcG9ydGluZyBpbmZvcm1hdGlvbiBhYm91dCBtdWx0aXBsZSBtZWRpYQ0Kc3Ry ZWFtcywgaW5jbHVkaW5nIGEgc3BlY2lmaWNhdGlvbiBvZiB2YXJpYWJsZXMgcmVxdWlyZWQgdG8g c3VwcG9ydCB0aGUNCnVzZSBjYXNlcy4gVGhpcyB3b3JrIGl0ZW0gd2lsbCBjb25zaWRlciB0aGUg cmV1c2Ugb2YgZXhpc3RpbmcgSUVURiBwcm90b2NvbHMNCmFuZCBwcm9kdWNlIGFuIGFyY2hpdGVj dHVyZS9wcm90b2NvbCBmcmFtZXdvcmsgZG9jdW1lbnQgZGVzY3JpYmluZyB0aGUNCnByb3RvY29s cyByZXF1aXJlZCB0byBiZSBpbXBsZW1lbnRlZCB0byBzdXBwb3J0IHRoaXMgZnVuY3Rpb25hbGl0 eS4gJm5ic3A7VGhlDQpkb2N1bWVudCB3aWxsIGlkZW50aWZ5IGFueSBlbmhhbmNlbWVudHMgcmVx dWlyZWQgdG8gZXhpc3RpbmcgcHJvdG9jb2xzDQphcyB3ZWxsIGFzIGRlc2NyaWJpbmcgbmV3IHBy b3RvY29sKHMpIGZvciBpbnRlcm9wZXJhYmxlIG11bHRpLXN0cmVhbXMgbmVnb3RpYXRpb24NCnRo YXQgbWF5IGJlIHJlcXVpcmVkLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxiPjxicj4NClNjb3BlPC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClRoZSBzY29wZSBpbmNs dWRlcyBib3RoIHN5c3RlbXMgdGhhdCBwcm92aWRlIGEgZnVsbHkgaW1tZXJzaXZlIGV4cGVyaWVu Y2UsDQphbmQgc3lzdGVtcyB0aGF0IGludGVyd29yayB3aXRoIHRoZW0gYW5kIHRoZXJlZm9yZSBu ZWVkIHRvIHVuZGVyc3RhbmQgdGhlDQpzYW1lIG11bHRpcGxlIHN0cmVhbSBzZW1hbnRpY3MuPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhlIGZvY3VzIG9m IHRoaXMgd29yayBpcyBvbiBhdWRpbyBhbmQgdmlkZW8gbXVsdGlwbGUgc3RyZWFtcywgaG93ZXZl cg0Kb3RoZXIgbWVkaWEgdHlwZXMgbWF5IGJlIGNvbnNpZGVyZWQuICZuYnNwO0RlZmluaXRpb24g b2YgbmV3IGFwcGxpY2F0aW9uDQpwcm90b2NvbHMgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2Yg dGhpcyB3b3JrPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CltJcyB0aGVyZSBhbnl0aGluZyBlbHNlIHdlIG5lZWQgdG8gZXhwbGljaXRseSBzYXkgaXMgb3V0 IG9mIHNjb3BlP108L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MmJmIGZhY2U9IkFyaWFsIj48YnI+DQogPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj48Yj48YnI+DQpUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlPC9iPjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPjxicj4NCi0gUmVxdWlyZW1lbnRzIGFuZCB1c2UgY2FzZXM8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+ DQogPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQotIEFyY2hpdGVjdHVyYWwgRnJhbWV3b3JrIGRl c2NyaWJpbmcgdGhlIHByb3RvY29scyByZXF1aXJlZCB0byBiZSBpbXBsZW1lbnRlZA0KdG8gc3Vw cG9ydCB0aGlzIGZ1bmN0aW9uYWxpdHkgYW5kIGlkZW50aWZ5aW5nIGV4aXN0aW5nIHByb3RvY29s IGVuaGFuY2VtZW50cw0KYW5kIG5ldyBwcm90b2NvbCBmdW5jdGlvbmFsaXR5IHJlcXVpcmVkPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCi0gU3BlY2lmaWNh dGlvbiBvZiBhIG5ldyBwcm90b2NvbCB0byBzdXBwb3J0IHRlbGVwcmVzZW5jZSBtdWx0aS1zdHJl YW1zDQpbaWYgcmVxdWlyZWRdPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+PGI+PGJyPg0KR29hbHMgYW5kIE1pbGVzdG9uZXM8L2I+PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0cj4N Cjx0ZCB3aWR0aD0xNyU+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5Ob3YgMjAxMCA8L2ZvbnQ+ DQo8dGQgd2lkdGg9ODIlPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+VXNlIENhc2VzIGFuZCBS ZXF1aXJlbWVudHMgdG8gSUVTRw0KYXMgSW5mb3JtYXRpb25hbCBSRkMgPC9mb250Pg0KPHRyPg0K PHRkPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+TWFyY2ggMjAxMSA8L2ZvbnQ+DQo8dGQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5BcmNoaXRlY3R1cmUgdG8gSUVTRyBhcyBJbmZvcm1hdGlv bmFsIFJGQw0KPC9mb250Pg0KPHRyPg0KPHRkPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+TWFy Y2ggMjAxMTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8 dGQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5SZXZpc2UgQ2hhcnRlciBbSUYgbmV3IHByb3Rv Y29sIGlzIG5vdCByZXF1aXJlZF08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pg0KPHRyPg0KPHRkPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+Tm92IDIwMTEg PC9mb250Pg0KPHRkPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+U3VibWl0IHByb3RvY29sIGRy YWZ0IHRvIElFU0cgYXMgUHJvcG9zZWQNClN0YW5kYXJkIFJGQyA8L2ZvbnQ+PC90YWJsZT4NCjxw Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0K IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8 YnI+DQpkaXNwYXRjaEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGlzcGF0Y2g8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4NClRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkDQp0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcw0KY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQNCndpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsDQpvciBlbnRp dHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4NCmVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQNCmluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMNCmFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZu YnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7 aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5i c3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2Vu ZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25h bWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50 YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRl ZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5i c3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJz cDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJz cDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtp bnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3 aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZu YnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7 ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhw cmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3Nl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNw O21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3Zp cnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0m bmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0006548B48257737_=-- From hakon.dahle@tandberg.com Wed Jun 2 22:10:51 2010 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 8F5B13A6A85 for ; Wed, 2 Jun 2010 22:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.752 X-Spam-Level: X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_05=-1.11, MIME_8BIT_HEADER=0.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 fvZBy8Qi6VGt for ; Wed, 2 Jun 2010 22:10:45 -0700 (PDT) Received: from mail194.messagelabs.com (mail194.messagelabs.com [85.158.140.211]) by core3.amsl.com (Postfix) with SMTP id CE1373A6A4F for ; Wed, 2 Jun 2010 22:10:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: hakon.dahle@tandberg.com X-Msg-Ref: server-14.tower-194.messagelabs.com!1275541831!38062214!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 4936 invoked from network); 3 Jun 2010 05:10:31 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-14.tower-194.messagelabs.com with SMTP; 3 Jun 2010 05:10:31 -0000 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jun 2010 07:10:30 +0200 Received: from 10.47.136.43 ([10.47.136.43]) by oslexcp1.eu.tandberg.int ([10.47.136.29]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Jun 2010 05:10:28 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 thread-topic: [dispatch] Updated charter/work description fortelepresencemulti-streams thread-index: AcsCqjjSwfLIbUWBQA+HnPLCAE5x3wABbUvDAAGRQ3AACTh9qA== Message-ID: <7367501cb02db$14fff901$2b882f0a@eu.tandberg.int> From: =?utf-8?B?SMOla29uIERhaGxl?= To: , , Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2010 05:10:30.0938 (UTC) FILETIME=[168947A0:01CB02DB] Date: 3 Jun 2010 07:10:30 +0200 Subject: Re: [dispatch] Updated charter/work description fortelepresencemulti-streams 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, 03 Jun 2010 05:10:52 -0000 Allyn,=0A= =0A= I agree with your suggestion.=0A= =0A= -h=0A= =0A= =0A= =0A= =0A= ----- Reply message -----=0A= From: "Allyn Romanow (allyn)" =0A= Date: Wed, Jun 2, 2010 17:53=0A= Subject: [dispatch] Updated charter/work description = fortelepresencemulti-streams=0A= To: "H=C3=A5kon Dahle" , "dispatch@ietf.org" = , "alex@vidyo.com" =0A= Hi Alex and Hakon,=20 I think the intent here is to say that we want to cover current use = cases and be extensible enough to cover new ones that may arise. I don't = think it valuable to exhaustively enumerate relevant dimensions of use = cases in this charter statement - that is better left to the use case = document.=20 How would it be to say, "This requires considering current widely deployed use cases, as well as = cases that are expected to be implemented using the protocol framework = produced by this work item. The methodology for describing the = variables must allow extensibility of the variables, since telepresence = is still a young technology and may have use cases that are not = currently considered." Allyn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of H=C3=A5kon Dahle Sent: Wednesday, June 02, 2010 5:02 PM To: dispatch@ietf.org Subject: Re: [dispatch] Updated charter/work description = fortelepresencemulti-streams Agree with Alex to a large extent in that scalability, simulcast, = publish/subscribe may all be applicable to the problem at hand. However I do not think the Charter should jump to conclusions on what = happens inside "the server" that Alex is referring to in his email - at = this point I suggest leaving these details out of the charter, to make = sure all options can be investigated. -h ----- Reply message ----- From: "Alex Eleftheriadis" Date: Wed, Jun 2, 2010 16:20 Subject: [dispatch] Updated charter/work description for = telepresencemulti-streams To: "H=C3=A5kon Dahle" Cc: "dispatch@ietf.org" Inline. On Jun 2, 2010, at 9:51 PM, H=C3=A5kon Dahle wrote: A comment on the following sentence in the updated charter: =E2=80=9CThis requires considering current widely deployed use cases, = such as single and multiple screens, multi-point, Scalable Video Coding = (SVC), as well as cases that are expected to be implemented using the = protocol framework produced by this work item. =E2=80=9D Addressing use cases such as single and multiple screen systems, as well = as both point-to-point and multi-point calling is great. However I do = not understand why a specific video codec or coding technique has been = added to the same context. The charter shouldn=E2=80=99t recommend or = limit the work for any specific codec (it should be codec agnostic), = and I suggest the charter should be changed to comply with this. Right. I believe that the correct reference is to alternative = architectures for the server in both point-to-point and multi-point = calls, where scalability (which includes simulcasting, pyramidal coding = such as SVC, and multiple description coding) lends itself to VRUs = (Video Routing Units) as opposed to MCUs. The VRU employs a "subscribe" = model, made possible by scalability, and which works quite differently = than an MCU. --Alex -h ________________________________ Fra: dispatch-bounces@ietf.org p=C3=A5 = vegne av Allyn Romanow (allyn) Sendt: on 02.06.2010 18:11 Til: dispatch@ietf.org; = mary.ietf.barnes@gmail.com; Cullen = Jennings (fluffy) Emne: [dispatch] Updated charter/work description for = telepresencemulti-streams Folks, Here is a version of the work description that addresses the comments = made on the first draft. The changes include: 1. Charter section, qualification that we are working on SIP-based = systems 2. Charter section, minor word smithing 3. Charter section, reference to RAI WG with relevant work 4. Scope section, clarification of interoperability requirements 5. Scope section, replacement of second paragraph regarding = treatment of non-video non-audio media types 6. Goals and Milestones =E2=80=93 addition of a Problem Statement = draft Comments welcome Allyn Multi-streams for Telepresence Description of Work Background One branch of video conferencing has evolved that is focused on = immersive =E2=80=9Cbeing there=E2=80=9D experience. Referred to in = various ways such as virtual conferencing, telepresence or media spaces, = early systems were mainly research projects or business systems with = limited deployments. In recent years telepresence systems have seen = considerable market success. Following the model of early systems, the = first wave of commercial systems have been typically located in = specially designed single-purpose rooms with multiple relatively large = displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones. These systems have several = important characteristics that are different from more traditional video = conferencing systems. The first difference concerns controlling the visual viewpoint in order = to improve participant nonverbal communication. These systems preserve = essential group meeting characteristics such as eye contact, group = gestures, seating order and spatial audio by carefully orchestrating the = miking and camera angles at each of the sites . This is distinct from = the more traditional approach where the geometric relationship between = media streams is not used to preserve inter-stream communication aspects = such as eye contact and group dynamics. A second difference is manipulation of the environment to improve = immersion. With telepresence systems, cinematographic aspects of the = local environment reproduction are carefully planned including color, = table shape, seating and lighting so that when combined with large high = quality displays, a strong sense of a "trompe l'oeil" or "being there" = immersive experience is created. Typical video conference systems do = not include these considerations. As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal = communication and immersive values of telepresence via smaller, less = expensive and more flexible video conferencing systems for a variety of = venues, such as individual offices, homes and kiosks. These are also = telepresence systems, since the audio and video quality is high enough = to allow clear image reproduction for nonverbal communication, they are = able to send and receive multiple media streams, and large coordinated = multi image displays are available for immersive installations. As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available. Problem Although telepresence systems are based on open standards such as RTP, = SIP, H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call. A major factor in the inability of Telepresence systems = to work with each other is that there is no standard description of the = multiple streams that comprise the media flows. For example, in a multiple screen conference, the video and audio = streams sent from remote participants must be understood by receivers so = that they can be presented in a coherent and life-like manner. This = includes the ability to present the remote participants at their true = size for their apparent distance, while maintaining correct eye contact, = gesticular cues, and simultaneously providing a spatial audio sound = stage consistent with the video presentation. The receiving device that = decides how to display the incoming information needs to understand a = number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is = related to each of the displays, etc. Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to = define and specify for SIP-based systems the content of media = multi-stream messages and the way these will be transported. This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference = bridges. It will specify variables that describe the semantics of the = media streams and the recommended behavior to achieve interoperability. This requires considering current widely deployed use cases, such as = single and multiple screens, multi-point, Scalable Video Coding (SVC), = as well as cases that are expected to be implemented using the protocol = framework produced by this work item. The methodology for describing = the variables must allow extensibility of the variables, since = telepresence is still a young technology and may have use cases that are = not currently considered. The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media = streams, including a specification of variables required to support the = use cases. This work item will consider the reuse of existing IETF = protocols and produce an architecture/protocol framework document = describing the protocols required to be implemented to support this = functionality. The document will identify any enhancements required to = existing protocols as well as describing new protocol(s) for = interoperable multi-streams negotiation that may be required. Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe. Scope The scope includes both systems that provide a fully immersive = experience, and systems that interwork with them and therefore need to = understand the same multiple stream semantics. The focus of this work is on audio and video multiple streams. Other = media types may be considered, however development of methodologies for = them is not within the scope of this work. Interoperation with standards compliant systems is required, such as = SIP-based video conferencing systems. However, backwards compatibility = with existing non-standards compliant telepresence systems is not = required. The group will produce - Requirements and use cases - Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing = protocol enhancements and new protocol functionality required - Specification of a new protocol to support telepresence multi-streams = [if required] Goals and Milestones Nov 2010 Use Cases and Requirements to IESG as Informational RFC Nov 2010 March 2011 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC March 2011 Revise Charter [IF new protocol is not required] Nov 2011 Submit protocol draft to IESG as Proposed Standard RFC _______________________________________________ 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 fluffy@cisco.com Thu Jun 3 09:27:01 2010 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 4E98D3A684C for ; Thu, 3 Jun 2010 09:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.451 X-Spam-Level: X-Spam-Status: No, score=-108.451 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 0xu9-cT6rnnc for ; Thu, 3 Jun 2010 09:26:57 -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 B9F4E3A6843 for ; Thu, 3 Jun 2010 09:26:57 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP9zB0yrR7H+/2dsb2JhbACeJXGlbZoXhRYEg0g X-IronPort-AV: E=Sophos;i="4.53,355,1272844800"; d="scan'208";a="206699940" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 03 Jun 2010 16:26:43 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o53GQgY8026469; Thu, 3 Jun 2010 16:26:43 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> Date: Thu, 3 Jun 2010 10:26:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <85126D80-2925-4DBB-8A53-D754B2C46452@cisco.com> References: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com> To: Milan Patel , DISPATCH list X-Mailer: Apple Mail (2.1078) Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI 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, 03 Jun 2010 16:27:01 -0000 I did a bit more thinking about how to make progress on this charter and = have a few ideas how to get the conversation going. The currently = charter is pretty unconstrained and does not explain what the problem is = the WG will solve. It roughly paraphrases to there are some bits in = some other telephone protocols that are not yet in SIP therefore we need = to put them in the tel URI. The IPTEL WG had pretty clear consigns that = was not an appropriate way to approach the problem and I would be = surprised to see that consensus has radically changed. I do think people = would be very favorable in putting in extensions that made sense to do = this way. My suggestion is to figure out what is the problems we are = actually trying to solve, then find a way to solve theses problems. I do = think there are problems to be solved that we do need some extensions - = it's just not clear where or how to do them. To help poke at what the = problem is, let me ask some questions that might get the conversation = going.=20 So the information being transported is roughly A tel URI to indicate = how the CIC code was selected. Why does the receiver need this = information and what are the use case for it? If we can be clear about = that, I think ti will help define what information needs to be moved and = then we can figure out the appropriate place to put it in the protocol.=20= In the prison use case, the use case seems to be "Allow a user to block = phone call that come from a prison". Is that about it or is there more? I don't understand the payphone use case. Is it "charge more the call if = it came from a payphone?" Can you list out all the information that is needed from the OLI/CPC and = they we can try and sort out the use cases for what parts a SIP device = needs to understand and what parts only need to be transported across = the SIP network.=20 Cullen On May 28, 2010, at 7:13 AM, Patel, Milan wrote: > Hello, > =20 > Attached is a charter proposal for a WG to be formed for work = pertaining to extensions to the tel URI =96 specifically, parameters for = carrying the DAI, CPC, OLI and RN required for primarily interworking = scenarios to ISUP/PSTN. > Feedback is appreciated. > Regards, > Milan > =20 > =20 > From: Patel, Milan=20 > Sent: Tuesday, May 25, 2010 11:16 AM > To: Cullen Jennings; 'mary.ietf.barnes@gmail.com'; Robert Sparks; = 'Gonzalo Camarillo' > Cc: R.Jesske@telekom.de; 'Sumanth Channabasappa' > Subject: Charter proposal > =20 > Hi all, > =20 > Attached is a charter proposal for a WG to be formed to handle = Internet Drafts pertaining to the Tel URI. Specifically these are the = DAI draft and the CPC/OLI draft and some further work on the RN = parameter. > Feedback is welcome. > =20 > Kind regards, > Milan > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jhaluska@telcordia.com Thu Jun 3 13:11:05 2010 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 0BB593A6895 for ; Thu, 3 Jun 2010 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 mC5ZYXDSVVuJ for ; Thu, 3 Jun 2010 13:10:43 -0700 (PDT) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by core3.amsl.com (Postfix) with ESMTP id 09B2F3A6811 for ; Thu, 3 Jun 2010 13:10:41 -0700 (PDT) Received: from pya-dte-ieg01.dte.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id o53KASGq011226 for ; Thu, 3 Jun 2010 16:10:28 -0400 (EDT) X-AuditID: 80601415-0000124000000554-43-4c080c307872 Received: from rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) by pya-dte-ieg01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jun 2010 16:10:24 -0400 Received: from rrc-dte-exmb2.dte.telcordia.com ([128.96.180.27]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Thu, 3 Jun 2010 16:10:24 -0400 From: "Haluska, John J" To: "dispatch@ietf.org" Date: Thu, 3 Jun 2010 16:10:23 -0400 Thread-Topic: RE: [dispatch] Charter proposal for drafts related to the tel URI Thread-Index: AcsDWMy5c0mE40AJQEuQgU5hFGwX9g== Message-ID: <8B6A9EC265011E4CB70F99C64426E8C2058636D1C9@rrc-dte-exmb2.dte.telcordia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B6A9EC265011E4CB70F99C64426E8C2058636D1C9rrcdteexmb2dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI 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, 03 Jun 2010 20:11:05 -0000 --_000_8B6A9EC265011E4CB70F99C64426E8C2058636D1C9rrcdteexmb2dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to state that I am strongly in favor of addressing this in the IET= F. Some of this information is very important to Operator Services and Dire= ctory Assistance, and continues to be important as we move forward towards = implementing these with SIP. We wrote a couple of drafts awhile back about = the need to signal certain information in SIP - e.g., draft-haluska-dispatc= h-csi-needed-00. As has been mentioned, this issue has been raised at least three times in t= he past decade. I believe this is an indication that this is a problem in n= eed of attention. [dispatch] Charter proposal for drafts related to the tel URI ________________________________ * From: "Patel, Milan" > * To: >, >, "Cullen Jennin= gs" > * Date: Fri, 28 May 2010 09:13:05 -0400 ________________________________ Hello, Attached is a charter proposal for a WG to be formed for work pertaining to= extensions to the tel URI - specifically, parameters for carrying the DAI,= CPC, OLI and RN required for primarily interworking scenarios to ISUP/PSTN= . Feedback is appreciated. Regards, Milan --_000_8B6A9EC265011E4CB70F99C64426E8C2058636D1C9rrcdteexmb2dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to state th= at I am strongly in favor of addressing this in the IETF. Some of this information = is very important to Operator Services and Directory Assistance, and continues= to be important as we move forward towards implementing these with SIP. We wro= te a couple of drafts awhile back about the need to signal certain information i= n SIP - e.g., draft-haluska-dispatch-csi-needed-00.

 

As has been mentioned, thi= s issue has been raised at least three times in the past decade. I believe this is = an indication that this is a problem in need of attention. <= /p>

 

 

 

 

 

 

 

[dispatch] Charter proposal for drafts related to the tel URI

He= llo,

&n= bsp;

At= tached is a charter proposal for a WG to be formed for work pertaining to extens= ions to the tel URI – specifically, parameters for carrying the DAI, CPC= , OLI and RN required for primarily interworking scenarios to ISUP/PSTN.

Fe= edback is appreciated.

Re= gards,

Mi= lan

&n= bsp;

&n= bsp;

 

--_000_8B6A9EC265011E4CB70F99C64426E8C2058636D1C9rrcdteexmb2dt_-- From dworley@avaya.com Thu Jun 3 18:30:03 2010 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 7A7F93A67F9 for ; Thu, 3 Jun 2010 18:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsIzf3Ae6u-C for ; Thu, 3 Jun 2010 18:30:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id EBA4D3A6405 for ; Thu, 3 Jun 2010 18:30:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,358,1272859200"; d="scan'208";a="191841353" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Jun 2010 21:29:46 -0400 X-IronPort-AV: E=Sophos;i="4.53,358,1272859200"; d="scan'208";a="469142752" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 03 Jun 2010 21:29:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 3 Jun 2010 21:29:43 -0400 From: "WORLEY, Dale R (Dale)" To: Richard Shockey , 'Paul Kyzivat' , "'Patel, Milan'" Date: Thu, 3 Jun 2010 21:25:12 -0400 Thread-Topic: [dispatch] Charter proposal for drafts related to the tel URI Thread-Index: Acr+bb4WC99ZYaI+SrKjhn1lTIubfQAGNW5KAAROPeABOz6o8g== Message-ID: References: <61CAF342FE1EE34EAC8FB19B765914000E6FB135@SABRE.InterDigital.com>, <4BFFCBC7.3070506@cisco.com> , <006d01cafe98$1fc94a50$5f5bdef0$@us> In-Reply-To: <006d01cafe98$1fc94a50$5f5bdef0$@us> 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: "dispatch@ietf.org" Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI 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, 04 Jun 2010 01:30:03 -0000 ________________________________________ From: Richard Shockey [richard@shockey.us] Though the larger issue of how to carry these types of messages or metadata (CNAM,CIC,SPID) in SIP has not been fully addressed either. Needless to say we have had a vigorous discussion over this ongoing issue i= n both DRINKS and the E2MD BOF ( NGN ENUM ) list. ________________________________________ I suspect that any truly useful solution will be similar to what is being s= olidified regarding translation Q.850 "response codes" into SIP so that SIP= can be used as a transit network between two SS7 networks: (1) As much as= possible, the *meaning* of the Q.850 code is translated into a SIP respons= e code, and (2) the original Q.850 code is carried directly in a way for wh= ich SIP is transparent, in order to be resurrected at a SIP-to-SS7 gateway. In the case of CIC and friends, carrying the codes directly in a suitable h= eader is quite appropriate. But I think that the approach of attaching the= m directly to the originating or destination URI is not architecturally sou= nd. Dale From Milan.Patel@InterDigital.com Fri Jun 4 03:41:10 2010 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 A87143A68FA for ; Fri, 4 Jun 2010 03:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH57XZL-tr+x for ; Fri, 4 Jun 2010 03:41:09 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id B160E3A6889 for ; Fri, 4 Jun 2010 03:41:09 -0700 (PDT) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 06:40:56 -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: Fri, 4 Jun 2010 06:40:55 -0400 Message-ID: <61CAF342FE1EE34EAC8FB19B765914000E6FB14B@SABRE.InterDigital.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter proposal for drafts related to the tel URI Thread-Index: Acr+bb4WC99ZYaI+SrKjhn1lTIubfQAGNW5KAAROPeABOz6o8gAStM/Q From: "Patel, Milan" To: "WORLEY, Dale R (Dale)" , "Richard Shockey" , "Paul Kyzivat" , "Cullen Jennings" X-OriginalArrivalTime: 04 Jun 2010 10:40:56.0081 (UTC) FILETIME=[69A7C810:01CB03D2] Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI 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, 04 Jun 2010 10:41:10 -0000 Hi Cullen, One thing needs to be made clear and that is the called party isn't required to handle the information. Especially in SIP, the CPC for example would be subject to trust domain rules. The information is required for SIP intermediaries, or in the case of interworking to the PSTN, the information is required for processing within the PSTN and not by the endpoint device or user.=20 Dale, the solutions currently proposed for the CPC/OLI/DAI is something that I believe is already deployed, and in your opinion, might not be the most architecturally sound solution, but we would need to factor into account current deployments.=20 Best regards, Milan -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of WORLEY, Dale R (Dale) Sent: Friday, June 04, 2010 2:25 AM To: Richard Shockey; 'Paul Kyzivat'; Patel, Milan Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI ________________________________________ From: Richard Shockey [richard@shockey.us] Though the larger issue of how to carry these types of messages or metadata (CNAM,CIC,SPID) in SIP has not been fully addressed either. Needless to say we have had a vigorous discussion over this ongoing issue in both DRINKS and the E2MD BOF ( NGN ENUM ) list. ________________________________________ I suspect that any truly useful solution will be similar to what is being solidified regarding translation Q.850 "response codes" into SIP so that SIP can be used as a transit network between two SS7 networks: (1) As much as possible, the *meaning* of the Q.850 code is translated into a SIP response code, and (2) the original Q.850 code is carried directly in a way for which SIP is transparent, in order to be resurrected at a SIP-to-SS7 gateway. In the case of CIC and friends, carrying the codes directly in a suitable header is quite appropriate. But I think that the approach of attaching them directly to the originating or destination URI is not architecturally sound. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Fri Jun 4 05:43:17 2010 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 F19C13A6983 for ; Fri, 4 Jun 2010 05:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI-2l0sJTi6Y for ; Fri, 4 Jun 2010 05:43:16 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 2970C3A67B3 for ; Fri, 4 Jun 2010 05:43:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,361,1272859200"; d="scan'208";a="221411388" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Jun 2010 08:42:45 -0400 X-IronPort-AV: E=Sophos;i="4.53,361,1272859200"; d="scan'208";a="469276691" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 04 Jun 2010 08:42:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 4 Jun 2010 08:42:44 -0400 From: "WORLEY, Dale R (Dale)" To: "Patel, Milan" , Richard Shockey , Paul Kyzivat , Cullen Jennings Date: Fri, 4 Jun 2010 08:41:18 -0400 Thread-Topic: [dispatch] Charter proposal for drafts related to the tel URI Thread-Index: Acr+bb4WC99ZYaI+SrKjhn1lTIubfQAGNW5KAAROPeABOz6o8gAStM/QAATn/9E= Message-ID: References: , <61CAF342FE1EE34EAC8FB19B765914000E6FB14B@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB14B@SABRE.InterDigital.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: "dispatch@ietf.org" Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI 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, 04 Jun 2010 12:43:17 -0000 ________________________________________ From: Patel, Milan [Milan.Patel@InterDigital.com] Dale, the solutions currently proposed for the CPC/OLI/DAI is something that I believe is already deployed, and in your opinion, might not be the most architecturally sound solution, but we would need to factor into account current deployments. _______________________________________________ Beware that those who come to the IETF to get blessed things that they have= already deployed are often disappointed. You cannot compel the IETF to ap= prove things. Dale From pkyzivat@cisco.com Fri Jun 4 06:37:08 2010 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 B9D553A69E5 for ; Fri, 4 Jun 2010 06:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.451 X-Spam-Level: X-Spam-Status: No, score=-8.451 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-5L9aMyspMN for ; Fri, 4 Jun 2010 06:37:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 746723A6A60 for ; Fri, 4 Jun 2010 06:37:07 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,361,1272844800"; d="scan'208";a="117976781" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Jun 2010 13:36:42 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o54DagGF020515; Fri, 4 Jun 2010 13:36:42 GMT Message-ID: <4C090170.6070702@cisco.com> Date: Fri, 04 Jun 2010 09:36:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Patel, Milan" References: <61CAF342FE1EE34EAC8FB19B765914000E6FB14B@SABRE.InterDigital.com> In-Reply-To: <61CAF342FE1EE34EAC8FB19B765914000E6FB14B@SABRE.InterDigital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter proposal for drafts related to the tel URI 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, 04 Jun 2010 13:37:08 -0000 Patel, Milan wrote: > Dale, the solutions currently proposed for the CPC/OLI/DAI is something > that I believe is already deployed, and in your opinion, might not be > the most architecturally sound solution, but we would need to factor > into account current deployments. We can certainly take that into account. But we don't rubber stamp everything that comes along that has been deployed. Architectural soundness is a very important consideration. Thanks, Paul > Best regards, > Milan > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of WORLEY, Dale R (Dale) > Sent: Friday, June 04, 2010 2:25 AM > To: Richard Shockey; 'Paul Kyzivat'; Patel, Milan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Charter proposal for drafts related to the tel > URI > > ________________________________________ > From: Richard Shockey [richard@shockey.us] > > Though the larger issue of how to carry these types of messages or > metadata > (CNAM,CIC,SPID) in SIP has not been fully addressed either. > > Needless to say we have had a vigorous discussion over this ongoing > issue in > both DRINKS and the E2MD BOF ( NGN ENUM ) list. > ________________________________________ > > I suspect that any truly useful solution will be similar to what is > being solidified regarding translation Q.850 "response codes" into SIP > so that SIP can be used as a transit network between two SS7 networks: > (1) As much as possible, the *meaning* of the Q.850 code is translated > into a SIP response code, and (2) the original Q.850 code is carried > directly in a way for which SIP is transparent, in order to be > resurrected at a SIP-to-SS7 gateway. > > In the case of CIC and friends, carrying the codes directly in a > suitable header is quite appropriate. But I think that the approach of > attaching them directly to the originating or destination URI is not > architecturally sound. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Mon Jun 7 08:19:45 2010 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 E315D3A6405 for ; Mon, 7 Jun 2010 08:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7NVE87VSCw3 for ; Mon, 7 Jun 2010 08:19:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1817E3A801D for ; Mon, 7 Jun 2010 06:51:46 -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.375.2; Mon, 7 Jun 2010 09:51:45 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 7 Jun 2010 09:51:42 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Mon, 7 Jun 2010 09:51:03 -0400 Thread-Topic: Final Charter for Session-ID? Thread-Index: AcsGSHgZL0wTjV5sT+STBshjpFRg+g== Message-ID: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Final Charter for Session-ID? 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, 07 Jun 2010 15:19:46 -0000 Howdy, I have heard no objections to this version of the charter (other than a deb= ate about how to solve it). =20 If you have any comments regarding the charter, please speak now. Thanks! -hadriel SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCO= TCH) Charter: ---------------------------------- The SIPSCOTCH working group is chartered to define a mechanism that allows = operators and monitoring equipment to correlate SIP messages and dialogs of= the same higher-level end-to-end "session" across multiple SIP device hops= for the same "message-flow", for the purpose of troubleshooting. In parti= cular, the mechanism must be able to allow such correlation across SIP B2BU= As of as many functional types as possible, such as Application Servers, So= ftswitches, PBXs, SBCs, etc. The definition of a higher-layer "session" of the same "message-flow" is no= t defined by SIP when it involves a B2BUA, and is difficult to normatively = define in practice. For the purposes of this WG charter's scope, two or mo= re dialogs of a B2BUA are correlated under any conditions where correlation= might aid troubleshooting, by identifying them as belonging to the same hi= gher-level session. Any solution documents from this working group may exp= and or constrain the scope of their mechanism's correlation, if the working= group so decides. Although other solutions may be possible, this working group will focus on = defining a new SIP Header field for such a purpose, similar to the Call-ID = header field, in order to provide a simple, easily deployable mechanism whi= ch can work across SIP domains. The SIP Call-ID header field value itself i= s not usable for such correlation, because many B2BUAs must create a new Ca= ll-ID value on their UAC "side" in order to function properly, and to compl= y with the rules of RFC 3261.=20 It should be noted that certain SIP B2BUAs perform a "topology-hiding" func= tion, as described in RFC 5853. The working group will take such functions= into account for the correlation mechanism, as well as provide guidance fo= r implementers of the mechanism to avoid triggering such a function for the= mechanism's header field value. Lastly, although in certain environments such a mechanism may be usable for= dialog correlation in SIP state machines, it is not the goal of this worki= ng group to address that usage. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 2010 - New header specification to IESG (PS) From petithug@acm.org Mon Jun 7 09:38:06 2010 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 EBAB728C226 for ; Mon, 7 Jun 2010 09:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.373 X-Spam-Level: X-Spam-Status: No, score=-98.373 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292, 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 bz143bBL5fIH for ; Mon, 7 Jun 2010 09:38:05 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 00B0A3A86C7 for ; Sun, 6 Jun 2010 09:16:48 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 1A31F6C98478; Sun, 6 Jun 2010 16:16:49 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id F04716C98470 for ; Sun, 6 Jun 2010 16:16:47 +0000 (UTC) Message-ID: <4C0BC9EE.90908@acm.org> Date: Sun, 06 Jun 2010 09:16:46 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Iceowl/1.0b1 Icedove/3.0.4 MIME-Version: 1.0 CC: DISPATCH list References: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB49@srvxchg> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 07 Jun 2010 16:38:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/02/2010 02:02 PM, Peter Musgrave wrote: >> Hi, >> >> I support this proposed work to be taken by IETF under a new working group. There are certainly concrete deliverables that would merit IETF consensus to spur multi-vendor >interoperability. > > > +1 I also support this work. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwLyewACgkQ9RoMZyVa61eAhACffSqfOiTHMnz6v2SAYMwmpMoi +DMAmwTn+JWRcUlXwnuXWnQG6YVQTvXO =FtOk -----END PGP SIGNATURE----- From mary.ietf.barnes@gmail.com Mon Jun 7 09:49:22 2010 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 F2C2F3A6A6A for ; Mon, 7 Jun 2010 09:49:21 -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 Kk8m4KLtpbZU for ; Mon, 7 Jun 2010 09:49:21 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A89543A9041 for ; Sun, 6 Jun 2010 14:09:19 -0700 (PDT) Received: by iwn42 with SMTP id 42so2761463iwn.31 for ; Sun, 06 Jun 2010 14:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=almG7CCboOzZLf92aBBbm9b3caAy+eAsLgXpR85v1Pk=; b=E/qSYTu4BzLQkfL5+sbkChGZ4vfPAsLsmI49NbQCLvd8uwR0VqPlwC1qojg2clcEOd Ujutqc3lI7LfgDeYSanIefo/XXSSJs8+g/V0wZQFrnaAHZAOlHGIJTpS/DD+DtRC+OKA jFgDI3a+ZJeaDLajlEUbA3iix4zznsWKoIH3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wkiXXnqIKFxeQRuETA8b5nTyv4BqKOca6q1rfT5wfBWh/yrtbiI89ooT+DExtpOQ3f ccnrfyeyg4FLQyMgIdSCfKmeShv8IGmnSGbLRPTo9Olgf16RPEka/vw9VDCi2HqOdH69 ZsU9TF5oXm4Bet+WRhhNVgZApaQlM2ube5RfA= MIME-Version: 1.0 Received: by 10.231.191.82 with SMTP id dl18mr3646444ibb.120.1275858556704; Sun, 06 Jun 2010 14:09:16 -0700 (PDT) Received: by 10.231.145.146 with HTTP; Sun, 6 Jun 2010 14:09:16 -0700 (PDT) Date: Sun, 6 Jun 2010 16:09:16 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Test - please ignore 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, 07 Jun 2010 16:49:22 -0000 Testing list. From R.Jesske@telekom.de Mon Jun 7 10:10:23 2010 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 4C6903A6C47 for ; Mon, 7 Jun 2010 10:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, NORMAL_HTTP_TO_IP=0.001, 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 YV1NWGtUp9Zb for ; Mon, 7 Jun 2010 10:10:20 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id A948428C43C for ; Sun, 6 Jun 2010 22:59:03 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 07 Jun 2010 07:59:01 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Jun 2010 07:59:00 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 7 Jun 2010 07:59:00 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason In responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKogA9AH9jA= References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> From: To: , X-OriginalArrivalTime: 07 Jun 2010 05:59:00.0823 (UTC) FILETIME=[869D7E70:01CB0606] Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) 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, 07 Jun 2010 17:10:23 -0000 Hi John, Thank you for your comments: Here are my view. REQ-1: I think that REQ-1 is still a justification, because not each Operator = will use SIP-T for tunnelling purposes. If you pass an untrusted domain SIP-T should not part, because it could = include restricted numbers or other information that should not be = presented to untrusted networks. Also only for passing the Q.850 Cause code to encapsulate the whole ISUP = is a little over dimensioned. The SIP-T MIME can be lost due to the interdomain trust relation ships = which the Reason header cannot. For in an multi carrier/service provider environment like Germany is, it = will not be secure that each operator will support SIP-T.=20 REQ-2 It must be possible to provide an accurate indication to a=20 UAC, so that the UAC can provide a suitable indication to the=20 user. So that is the proposal for REQ-2. REQ-3=20 A UA may have the ability to display ISUP specific release causes or show a equivalent text. So that would be sufficient enough for REQ-3. If people would like to = see such text. REQ-3/4 Your comment with regard to the type of UA is correct. I tried to = satisfy people. The fact is that is not intended to include the Q.850 = cause by an SIP end device. So the conclusion is changing REQ-3 and = deleting REQ-4. So now I would like to ask the people which requirements they would like = to see in the draft. As I understand John he sees only one (REQ-2) I propose REQ-1, -2 and -3. Opinions? Thank you and Best Regards Roland Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628-2766 (Tel.) +49 521 9210-3753 (Fax) +49 171 8618-445 (Mobil) E-Mail: mailto:r.jesske@telekom.de http://www.telekom.com =20 Erleben, was verbindet.=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht = jede E-Mail drucken. -----Urspr=FCngliche Nachricht----- Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Gesendet: Dienstag, 18. Mai 2010 21:37 An: Jesske, Roland; dispatch@ietf.org Betreff: RE: Reason In = responses(draft-jesske-dispatch-reason-in-responses-02) Roland,=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: 18 May 2010 15:57 > To: Elwell, John; dispatch@ietf.org > Subject: AW: Reason In=20 > responses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Hi John, > Thank you for your comments.=20 > It was asked to split the draft into requirements and at=20 > least procedures. >=20 > You are right that within the requirements draft is more that=20 > requirements. It is also the motivation, justification and=20 > examples. I can change the title if people are happy with it.=20 > Question is if such a draft is also needed as RFC or if it=20 > only seen as a temporary document during the discussion. [JRE] I was not proposing a title change, and I have no problem = combining motivation with requirements, although I do feel the examples = look too much like solution and are unnecessary. Although some people = asked you to split the draft, in my opinion it was wasted effort, but it = is done now. >=20 > With regard to REQ-1 I propose the following re-wording: >=20 > It should be possible to support within native SIP=20 > environment PSTN-SIP-PSTN scenarios where the reason of a=20 > call release can be transferred though the SIP domain > without any loss of information and no change of reason. >=20 > I think this was discussed lengthy during the last meeting=20 > and email discussion. > Not each PSTN GW will support ISUP MIME encapsulation. At=20 > least the 3GPP IMS has no SIP. The IMS is not using SIP-T. [JRE] I don't think the new wording makes any difference. SIP-T is a = means for tunnelling a Q.850 cause through a native SIP domain. The IETF = already defines SIP-T as the solution, and if this solution is not = sufficient, you need to cite reasons why not and identify a requirement = that cannot be met using SIP-T. Just saying that IMS does not use SIP-T = doesn't sound like a sufficient reason to me, because clearly IMS could = be made to use SIP-T. To be clear, I am not saying that the Reason header field should not be = used in this situation, if the header field is defined for use in = responses in general in order meet other requirements. I am simply = saying that REQ-1 is not sufficient justification for allowing the = Reason header field in responses, since REQ-1 can be satisfied using an = existing mechanism. >=20 > REQ-2 and REQ-3 > Yes it looks similar. >=20 > REQ-3 was added because it was seen from user device=20 > perspective that the Device have the possibility to show the=20 > Q.850 cause but that such a End Device does not include Q.850=20 > causes. Of course a MGC should have this possibility. >=20 > I would be happy to shrink REQ-2 and 3 to your proposed text. >=20 > REQ-2 > It must be possible to provide an accurate indication to a=20 > UAC, so that the UAC can provide a suitable indication to the=20 > user. Whether this be an announcement, a textual message, an=20 > icon, a flashing lamp, a tone, a vibration, an odour or=20 > whatever, is a user interface matter. [JRE] I did not intend the second sentence to be part of the requirement = - it was just for illustration of why the existing text, which focused = on textual display, was inadequate. >=20 > REQ-4 was the consequence of REQ-3 where we do not allow the=20 > inclusion of a Q850 cause by a end device. >=20 > So the trick is not allow the SIP end device to include a=20 > Q850 cause and in some certain cases to allow an service=20 > provider controlled application server to include a Reason=20 > header with a Q.850 cause. But it should not be done=20 > generally by SIP applications. So normally a ISUP=20 > implementation will use ISUP causes but not SIP implementations. > But there are SIP Application servers out in the world that=20 > will have a ISUP application (or ISUP like application that=20 > reacts and behaves as within a ISUP network). [JRE] I found REQ-3 rather confusing. On re-reading it, the first = sentence is a requirement concerning reception, and the second sentence = seems (if I understand correctly) to be a statement about sending. = Assuming my understanding is correct, making a statement, within a = requirement, that something is out of scope seems to suggest it is not = part of the requirement. In addition, the way SIP is specified, there is no real distinction = between different types of UA. In other words, SIP procedures for UAs = apply to UAs in general, not to specific types of UA like ASs. So = writing a requirement that tries to distinguish between different types = of UA does not seem to make sense. >=20 > Question is now how to proceed further. >=20 > Are people happy to have the documents split or put again=20 > together with striking out the examples ect? > Or to have the documents as they are with some transfer of=20 > text to the draft-jesske-dispatch-reason-in-responses-02 draft? [JRE] I don't have a strong opinion about document structure, although = my personal preference would have been to leave it as one document, as = it was originally. My main concern is trying to come up with a = meaningful set of requirements, and in my opinion it reduces to a single = requirement - being able to convey a Q.850 cause from PSTN (or similar) = to a UAC so that the UAC can render meaningful information to the user. John >=20 > Comments? >=20 > Thank you and Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Gesendet: Donnerstag, 13. Mai 2010 09:24 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: Reason In=20 > responses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Roland, >=20 > In my view, there is a simple requirement to convey Q.850=20 > causes in SIP response messages, so that the UAC will receive=20 > a more accurate indication of the reason for rejection when=20 > rejection comes from PSTN. The cause mapping table helps to=20 > illustrate this. This is not rocket science, and I am=20 > disappointed that we have not found a quick way of=20 > dispatching this and just getting the work done. In my=20 > opinion the split into separate documents was unnecessary=20 > (take as an example the recently-published RFC 5876, which=20 > combines motivation and solution in one document), but it has=20 > been done now. Unfortunately I don't think it has moved us=20 > any further forward. >=20 > I don't think the requirements in section 3 are particularly=20 > well expressed. REQ-1 can already be met by tunnelling in=20 > accordance with SIP-T. I would not expect the IETF to provide=20 > a new solution specifically for that requirement. >=20 > I think REQ-2 and REQ-3 boil down to the same thing - it must=20 > be possible to provide an accurate indication to a UAC, so=20 > that the UAC can provide a suitable indication to the user.=20 > Whether this be an announcement, a textual message, an icon,=20 > a flashing lamp, a tone, a vibration, an odour or whatever,=20 > is a user interface matter. >=20 > I also find REQ-4 rather problematic. If we have a solution=20 > for PSTN, we would also have a solution for some other form=20 > of gateway into a domain that provides a "PSTN-like service".=20 > Unfortunately, if you try to bring this out as a separate=20 > requirement, it raises the question of what exactly is this=20 > "PSTN-like service", and if it is somehow SIP-based, why it=20 > needs to be "PSTN-like", and so on. >=20 > Basically I think there is only a single requirement here -=20 > provision of a correct indication to a UAC when rejection=20 > comes from the PSTN. I think that is a reasonable requirement=20 > and we should just go ahead and do it, rather like we did=20 > with RFC 5876 when we extended the range of messages that=20 > PAI/PPI could be used in. >=20 > I find the statement in REQ-3 "A inclusion of [Q.850] causes=20 > is out of scope." very strange. I thought the whole idea was=20 > to convey Q.850 causes, so why say they are out of scope? I=20 > assume this is some sort of typo. >=20 > I think one of the consequences of deciding to split=20 > requirements and solution into separate drafts is that the=20 > requirements draft has to stick to motivation and=20 > requirements. I find too much in the draft (particularly the=20 > examples) that smells of solution. >=20 > John >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > > [mailto:dispatch-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > > Sent: 13 May 2010 03:05 > > To: dispatch@ietf.org > > Subject: Re: [dispatch] Reason In responses=20 > > (draft-jesske-dispatch-reason-in-responses-02) > >=20 > > Dear all,=20 > > I have asked for comments on the two drafts mentioned below.=20 > > So far I didn't get any. Does that mean that people are happy=20 > > now with the content and we could proceed with it?=20 > >=20 > > Thank you and Best Regrads=20 > >=20 > > Roland=20 > >=20 > >=20 > > _____________________________________________=20 > > Von: Jesske, Roland =20 > > Gesendet: Donnerstag, 8. April 2010 09:46=20 > > An: dispatch@ietf.org=20 > > Betreff: Reason In responses=20 > > (draft-jesske-dispatch-reason-in-responses-02)=20 > >=20 > > Dear all,=20 > > During the discussion concerning the Reason header field in=20 > > Responses I was asked to split the document into an=20 > > requirements part and an protocol part. > >=20 > > So please feel free to comment on the drafts.=20 > >=20 > > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-respo > > nses-02=20 > > > onses-02> =20 > >=20 > > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-r > > esponses-00=20 > > > responses-00> =20 > >=20 > > Best regards=20 > >=20 > > Roland Jesske=20 > >=20 > >=20 > > Deutsche Telekom Netzproduktion GmbH=20 > > Zentrum Technik Einf=FChrung=20 > > Roland Jesske=20 > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > > +49 6151 628-2766 (Tel.)=20 > > +49 521 9210-3753 (Fax)=20 > > +49 171 8618-445 (Mobil)=20 > > E-Mail: r.jesske@telekom.de =20 > > www.telekom.com =20 > >=20 > > Erleben, was verbindet.=20 > >=20 > > Deutsche Telekom Netzproduktion GmbH=20 > > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > > Albert Matheis, Klaus Peren=20 > > Handelsregister: Amtsgericht Bonn HRB 14190=20 > > Sitz der Gesellschaft: Bonn=20 > > USt-IdNr. DE 814645262=20 > >=20 > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > > nicht jede E-Mail drucken.=20 > >=20 > >=20 > >=20 >=20 From Even.roni@huawei.com Tue Jun 8 13:46:40 2010 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 22CFE3A684A for ; Tue, 8 Jun 2010 13:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 C3UOVD+-nTg0 for ; Tue, 8 Jun 2010 13:46:27 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4DD573A67C2 for ; Tue, 8 Jun 2010 13:46:27 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3P00LI6R16W8@szxga05-in.huawei.com> for dispatch@ietf.org; Wed, 09 Jun 2010 04:46:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3P00ED8R153G@szxga05-in.huawei.com> for dispatch@ietf.org; Wed, 09 Jun 2010 04:46:18 +0800 (CST) Received: from windows8d787f9 (bzq-109-65-51-207.red.bezeqint.net [109.65.51.207]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3P00BMVR0RSE@szxml01-in.huawei.com>; Wed, 09 Jun 2010 04:46:17 +0800 (CST) Date: Tue, 08 Jun 2010 23:43:45 +0300 From: Roni Even In-reply-to: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0176100E@xmb-sjc-221.amer.cisco.com> To: "'Allyn Romanow (allyn)'" , dispatch@ietf.org, mary.ietf.barnes@gmail.com, "'Cullen Jennings (fluffy)'" Message-id: <061701cb074b$50bdd1b0$f2397510$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_76NPZnPMVDGGYmoMyNOytQ)" Content-language: en-us Thread-index: AcsCblSSO/TS3HADTeGaueXI6GRStAE213qw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0176100E@xmb-sjc-221.amer.cisco.com> Subject: Re: [dispatch] Updated charter/work description for telepresence multi-streams 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, 08 Jun 2010 20:46:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_76NPZnPMVDGGYmoMyNOytQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I think this work is important and would like to see it addressed. The first issue I see is that currently when the SDP offer includes multiple m-lines of the same media type which typically will have different semantics, it is not clear how the answerer will select the right streams and render them correctly. The content attribute provide some information about the type of the stream but it does not discuss the application usage in a way that will help interoperability. I believe that the use case and requirements will provide more information about the interoperability issues for this application and I think that this work will allow us to develop similar solutions for other use cases that use multiple media stream of the same media type . Roni Even From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: Wednesday, June 02, 2010 7:12 PM To: dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen Jennings (fluffy) Subject: [dispatch] Updated charter/work description for telepresence multi-streams Folks, Here is a version of the work description that addresses the comments made on the first draft. The changes include: 1. Charter section, qualification that we are working on SIP-based systems 2. Charter section, minor word smithing 3. Charter section, reference to RAI WG with relevant work 4. Scope section, clarification of interoperability requirements 5. Scope section, replacement of second paragraph regarding treatment of non-video non-audio media types 6. Goals and Milestones - addition of a Problem Statement draft Comments welcome Allyn Multi-streams for Telepresence Description of Work Background One branch of video conferencing has evolved that is focused on immersive "being there" experience. Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments. In recent years telepresence systems have seen considerable market success. Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones. These systems have several important characteristics that are different from more traditional video conferencing systems. The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the miking and camera angles at each of the sites . This is distinct from the more traditional approach where the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. A second difference is manipulation of the environment to improve immersion. With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating and lighting so that when combined with large high quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is created. Typical video conference systems do not include these considerations. As telepresence video systems have become successful in the market, manufacturers have started exploring delivery of the nonverbal communication and immersive values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, homes and kiosks. These are also telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, and large coordinated multi image displays are available for immersive installations. As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available. Problem Although telepresence systems are based on open standards such as RTP, SIP, H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vendor to another. It would be like having to make sure all parties are on the same equipment (and network) when making a telephone call. A major factor in the inability of Telepresence systems to work with each other is that there is no standard description of the multiple streams that comprise the media flows. For example, in a multiple screen conference, the video and audio streams sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability to present the remote participants at their true size for their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously providing a spatial audio sound stage consistent with the video presentation. The receiving device that decides how to display the incoming information needs to understand a number of variables such as the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media stream is related to each of the displays, etc. Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify for SIP-based systems the content of media multi-stream messages and the way these will be transported. This work will provide a standard for the exchange of media semantic information that will foster interoperable end stations and conference bridges. It will specify variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability. This requires considering current widely deployed use cases, such as single and multiple screens, multi-point, Scalable Video Coding (SVC), as well as cases that are expected to be implemented using the protocol framework produced by this work item. The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technology and may have use cases that are not currently considered. The work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required to be implemented to support this functionality. The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be required. Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and FECframe. Scope The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. The focus of this work is on audio and video multiple streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. The group will produce - Requirements and use cases - Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality required - Specification of a new protocol to support telepresence multi-streams [if required] Goals and Milestones Nov 2010 Use Cases and Requirements to IESG as Informational RFC Nov 2010 March 2011 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC March 2011 Revise Charter [IF new protocol is not required] Nov 2011 Submit protocol draft to IESG as Proposed Standard RFC --Boundary_(ID_76NPZnPMVDGGYmoMyNOytQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I think this work is = important and would like to see it addressed.

 

The first issue I see = is that currently when the SDP offer includes multiple m-lines of the same media = type which typically will have different semantics, it is not clear how the = answerer will select the right streams and render them correctly.  The content = attribute provide some information about the type of the stream but it does not = discuss the application usage in a way that will help interoperability. I = believe that the use case and requirements will provide more information about the = interoperability issues for this application and I think that this work will allow us to = develop similar solutions for other use cases that use multiple media stream of = the same media type .

 

Roni = Even

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Allyn Romanow (allyn)
Sent: Wednesday, June 02, 2010 7:12 PM
To: dispatch@ietf.org; mary.ietf.barnes@gmail.com; Cullen = Jennings (fluffy)
Subject: [dispatch] Updated charter/work description for = telepresence multi-streams

 

Folks,

Here is a version of the work description that = addresses the comments made on the first draft.

The changes include:

1.       Charter section, = qualification that we are working on SIP-based systems

2.       Charter section, minor = word smithing

3.       Charter section, = reference to RAI WG with relevant work

4.       Scope section, = clarification of interoperability requirements

5.       Scope section, = replacement of second paragraph regarding treatment of non-video non-audio media = types

6.       Goals and Milestones = – addition of a Problem Statement draft

 

 

Comments welcome

 

Allyn

 

Multi-streams for = Telepresence Description of Work

 

 

 

Background

One branch of video conferencing has evolved that is focused on immersive “being there” experience.  Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were mainly research = projects or business systems with limited deployments.  In recent years = telepresence systems have seen considerable market success.  Following the model = of early systems, the first wave of commercial systems have been typically = located in specially designed single-purpose rooms with multiple relatively = large displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones.  These systems have several important characteristics that are different from more traditional video = conferencing systems. 

 

The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, seating = order and spatial audio by carefully orchestrating the miking and camera angles at = each of the sites . This is distinct from the more traditional approach where = the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics. 

 

A = second difference is manipulation of the environment to improve = immersion.  With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating = and lighting so that when combined with large high quality displays, a = strong sense of a "trompe l'oeil" or "being there" immersive = experience is created.  Typical video conference systems do not include these considerations.

 

As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal communication and = immersive values of telepresence via smaller, less expensive and more flexible = video conferencing systems for a variety of venues, such as individual = offices, homes and kiosks. These are also  telepresence systems, since the audio = and video quality is high enough to allow clear image reproduction for = nonverbal communication, they are able to send and receive multiple media streams, = and large coordinated multi image displays are available for immersive installations.   As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly = available.

 

Problem<= /p>

Although telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one = vendor to another. It would be like having to make sure all parties are on the = same equipment (and network) when making a telephone call.  A major = factor in the inability of Telepresence systems to work with each other is that = there is no standard description of the multiple streams that comprise the media = flows.

 

For example, in a multiple screen conference, the video and audio streams sent from = remote participants must be understood by receivers so that they can be = presented in a coherent and life-like manner. This includes the ability to present the = remote participants at their true size for their apparent distance, while = maintaining correct eye contact, gesticular cues, and simultaneously providing a = spatial audio sound stage consistent with the video presentation.  The = receiving device that decides how to display the incoming information needs to = understand a number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is related to = each of the displays, etc.

 

Charter<= /p>

The Telepresence Multi-Streams work item in DISPATCH is chartered to define = and specify for SIP-based systems the content of media multi-stream messages = and the way these will be transported.

 

This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference bridges. It = will specify  variables that describe the semantics of the media streams = and the recommended behavior to achieve interoperability.  =

 

This requires considering current widely deployed use cases, such as single = and multiple screens, multi-point, Scalable Video Coding (SVC), as well as = cases that are expected to be implemented using the protocol framework = produced by this work item.  The methodology for describing the variables must = allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently = considered.

 

The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media streams, = including a specification of variables required to support the use cases. This = work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality.  The document will = identify any enhancements required to existing protocols as well as describing = new protocol(s) for interoperable multi-streams negotiation that may be = required.

 

Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe.

 

Scope

The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple = stream semantics.

 

 

The focus of this work is on audio and video multiple streams.  Other = media types may be considered, however development of methodologies for them = is not within the scope of this work.

 

Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems.  However, backwards compatibility with = existing non-standards compliant telepresence systems is not = required.

 

 

 

The group will produce

- Requirements and use cases

 

- Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing protocol = enhancements and new protocol functionality required

 

- Specification of a new protocol to support telepresence multi-streams = [if required]

 

Goals and Milestones

Nov 2010

 

Use Cases and Requirements to IESG as Informational RFC

Nov 2010

March 2011

Problem Statement to IESG as Informational RFC

Architecture to IESG as Informational RFC

March 2011

Revise Charter [IF new protocol is not required]

Nov 2011

Submit protocol draft to IESG as Proposed Standard RFC

 

 

 

--Boundary_(ID_76NPZnPMVDGGYmoMyNOytQ)-- From mary.ietf.barnes@gmail.com Tue Jun 8 14:44:01 2010 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 BB9153A67D4 for ; Tue, 8 Jun 2010 14:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdRbudPhU25n for ; Tue, 8 Jun 2010 14:44:00 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8200F3A67C0 for ; Tue, 8 Jun 2010 14:44:00 -0700 (PDT) Received: by iwn42 with SMTP id 42so5082266iwn.31 for ; Tue, 08 Jun 2010 14:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=szCy4s/Ix+6gPbzmB6rIlyxfYShBPTib02tju5mqC5U=; b=nftfE8Si3z502wWETkw7Yz9o9wNAxGNV+dy0udygBhI5h2EroOfojZS0AkaUX5Pvfm IMgTaToTrs2/QfHUNTPxyVOr8FzazPvE4LizGJCHcTs066VYaM7yx7DTOxW84F0eTOWF B1YIhl+Vni3N47ZxNhzoBH6omIygXRFuauS10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=j86Y6sermBOF/7461P/NDDH003KaC2+cdR0nn5B/LR4vVVsfUFq1tivpMmRnbIN/h2 ij0WGficPWZF7ixg6qR7iZIzBp7wVAzZKM0i8WHBBeVyEXFzUBD4efgRt4X/QUyI65rY jz5+JJ1kznP5kPIlDFy4resgNYoRpZiEU89XA= MIME-Version: 1.0 Received: by 10.231.187.29 with SMTP id cu29mr2201395ibb.70.1276033439211; Tue, 08 Jun 2010 14:43:59 -0700 (PDT) Received: by 10.231.145.146 with HTTP; Tue, 8 Jun 2010 14:43:59 -0700 (PDT) Date: Tue, 8 Jun 2010 16:43:59 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Sparks , Gonzalo Camarillo Subject: [dispatch] DISPATCH-78 topics 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, 08 Jun 2010 21:44:01 -0000 Hi all, Per the reminder posted on the ML on May 4th and as listed on the DISPATCH WG wiki, charter proposals for the topics to be handled/dispatched prior to and at IETF-78 were due on May 31st. We received charter proposals (problem statements/deliverables) for the following, with links to most recent charter proposals and discussion threa= ds. o Session-ID: =A0updated charter proposal available http://www.ietf.org/mail-archive/web/dispatch/current/msg01967.html o Telepresence: =A0updated charter proposal available http://www.ietf.org/mail-archive/web/dispatch/current/msg01936.html o VIPR: =A0charter proposal http://www.ietf.org/mail-archive/web/dispatch/current/msg01930.html o TEL URI WG proposal: =A0discussion to focus on problem statement and scop= e http://www.ietf.org/mail-archive/web/dispatch/current/msg01920.html The above items are the current targets for IETF-78 discussions. =A0Based on those discussions, agenda time will be allocated, items dispatched and adhocs scheduled as appropriate. Note, that the minimum time we would allocate to a topic is 30 minutes and some may warrant 45 minutes. If we schedule adhocs, we will try to have those announced around the time the agenda is finalized. The following items have also been discussed on the mailing list, but are not yet ready for dispatching: o NGN Reason: Some interest. Needs more discussion and scoping. http://datatracker.ietf.org/doc/draft-jesske-dispatch-reason-in-responses/ http://datatracker.ietf.org/doc/draft-jesske-dispatch-req-reason-in-respons= es/ o PAN - wait for more energy http://datatracker.ietf.org/doc/draft-lawrence-sipforum-provider-alias/ o =A0ACH - ACH analysis draft to happen as part of BLISS wind down http://datatracker.ietf.org/doc/draft-ietf-bliss-ach-analysis/ o =A0ACH - HTTP API docs - need some hallway discussions http://datatracker.ietf.org/doc/draft-yusef-dispatch-ach-rest-api/ o =A0Media security - needs additional ML discussion http://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-parameter/ o Communication diversion and barring notification - feedback thus far needs to be considered - i.e, problem statement to be clarified and alternate solutions to be consider (Note: IPR on the communication diversion draft) http://datatracker.ietf.org/doc/draft-avasarala-dispatch-comm-div-notificat= ion/ http://datatracker.ietf.org/doc/-avasarala-dispatch-comm-barring-notificati= on/ As a reminder, the following are the cutoffs for drafts, so please make sure that any drafts relevant to the topic are submitted prior to those deadlines: * - 00 documents: =A0July 5th (< 4 weeks) * all other documents: July 12th (< 5 weeks) Please keep in mind that the focus of discussions should be the problem statement, scope and proposed deliverables for the topic. As a reminder, items can be dispatched without being discussed at a f2f meeting and the most effective way to achieve this is to have problem statements, scope of topics and any relevant documents available for discussion, rather than documents focusing on solutions. Please, let the chairs know if there are any concerns. Thanks, Mary Barnes and Cullen Jennings DISPATCH WG chairs From alex@vidyo.com Wed Jun 9 00:10:27 2010 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 9AAE93A68FD for ; Wed, 9 Jun 2010 00:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 MhrD99ln9X1C for ; Wed, 9 Jun 2010 00:10:23 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 555313A68DC for ; Wed, 9 Jun 2010 00:10:17 -0700 (PDT) Received: from BH011.mail.lan ([10.110.21.111]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 03:10:18 -0400 Received: from HUB011.mail.lan ([10.110.17.11]) by BH011.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Jun 2010 03:10:09 -0400 Received: from BE235.mail.lan ([10.110.32.235]) by HUB011.mail.lan ([10.110.17.11]) with mapi; Wed, 9 Jun 2010 03:10:12 -0400 From: Alex Eleftheriadis To: "Allyn Romanow (allyn)" Date: Wed, 9 Jun 2010 03:10:15 -0400 Thread-Topic: [dispatch] Updated charter/work description fortelepresencemulti-streams Thread-Index: AcsHotAQZDBypbwVRu+WVN+hKjPJsA== Message-ID: References: <7326301cb02af$ee00b17b$2b882f0a@eu.tandberg.int> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01817DFF@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01817DFF@xmb-sjc-221.amer.cisco.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jun 2010 07:10:09.0644 (UTC) FILETIME=[CBDB62C0:01CB07A2] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated charter/work description fortelepresencemulti-streams 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, 09 Jun 2010 07:10:27 -0000 Sure, that's fine.=20 --Alex On Jun 3, 2010, at 3:53 AM, Allyn Romanow (allyn) wrote: > Hi Alex and Hakon,=20 >=20 > I think the intent here is to say that we want to cover current use cases= and be extensible enough to cover new ones that may arise. I don't think i= t valuable to exhaustively enumerate relevant dimensions of use cases in th= is charter statement - that is better left to the use case document.=20 >=20 > How would it be to say, >=20 > "This requires considering current widely deployed use cases, as well as = cases that are expected to be implemented using the protocol framework prod= uced by this work item. The methodology for describing the variables must = allow extensibility of the variables, since telepresence is still a young t= echnology and may have use cases that are not currently considered." >=20 >=20 > Allyn >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of H=E5kon Dahle > Sent: Wednesday, June 02, 2010 5:02 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] Updated charter/work description fortelepresencem= ulti-streams >=20 >=20 > Agree with Alex to a large extent in that scalability, simulcast, publis= h/subscribe may all be applicable to the problem at hand. >=20 > However I do not think the Charter should jump to conclusions on what hap= pens inside "the server" that Alex is referring to in his email - at this p= oint I suggest leaving these details out of the charter, to make sure all o= ptions can be investigated. >=20 > -h >=20 >=20 >=20 > ----- Reply message ----- > From: "Alex Eleftheriadis" > Date: Wed, Jun 2, 2010 16:20 > Subject: [dispatch] Updated charter/work description for telepresencemult= i-streams > To: "H=E5kon Dahle" > Cc: "dispatch@ietf.org" >=20 > Inline. >=20 > On Jun 2, 2010, at 9:51 PM, H=E5kon Dahle wrote: >=20 > A comment on the following sentence in the updated charter: >=20 > =93This requires considering current widely deployed use cases, such as s= ingle and multiple screens, multi-point, Scalable Video Coding (SVC), as we= ll as cases that are expected to be implemented using the protocol framewor= k produced by this work item. =94 >=20 > Addressing use cases such as single and multiple screen systems, as well = as both point-to-point and multi-point calling is great. However I do not = understand why a specific video codec or coding technique has been added to= the same context. The charter shouldn=92t recommend or limit the work for= any specific codec (it should be codec agnostic), and I suggest the chart= er should be changed to comply with this. >=20 > Right. I believe that the correct reference is to alternative architectur= es for the server in both point-to-point and multi-point calls, where scala= bility (which includes simulcasting, pyramidal coding such as SVC, and mult= iple description coding) lends itself to VRUs (Video Routing Units) as oppo= sed to MCUs. The VRU employs a "subscribe" model, made possible by scalabil= ity, and which works quite differently than an MCU. >=20 > --Alex >=20 >=20 >=20 > -h >=20 > ________________________________ > Fra: dispatch-bounces@ietf.org p=E5 veg= ne av Allyn Romanow (allyn) > Sendt: on 02.06.2010 18:11 > Til: dispatch@ietf.org; mary.ietf.barnes@gmail.= com; Cullen Jennings (fluffy) > Emne: [dispatch] Updated charter/work description for telepresencemulti-s= treams > Folks, > Here is a version of the work description that addresses the comments mad= e on the first draft. > The changes include: > 1. Charter section, qualification that we are working on SIP-based = systems > 2. Charter section, minor word smithing > 3. Charter section, reference to RAI WG with relevant work > 4. Scope section, clarification of interoperability requirements > 5. Scope section, replacement of second paragraph regarding treatme= nt of non-video non-audio media types > 6. Goals and Milestones =96 addition of a Problem Statement draft >=20 >=20 > Comments welcome >=20 > Allyn >=20 > Multi-streams for Telepresence Description of Work >=20 >=20 >=20 > Background > One branch of video conferencing has evolved that is focused on immersive= =93being there=94 experience. Referred to in various ways such as virtual= conferencing, telepresence or media spaces, early systems were mainly rese= arch projects or business systems with limited deployments. In recent year= s telepresence systems have seen considerable market success. Following th= e model of early systems, the first wave of commercial systems have been ty= pically located in specially designed single-purpose rooms with multiple re= latively large displays permitting life size image reproduction, multiple c= ameras, encoders, decoders and microphones. These systems have several imp= ortant characteristics that are different from more traditional video confe= rencing systems. >=20 > The first difference concerns controlling the visual viewpoint in order t= o improve participant nonverbal communication. These systems preserve essen= tial group meeting characteristics such as eye contact, group gestures, sea= ting order and spatial audio by carefully orchestrating the miking and came= ra angles at each of the sites . This is distinct from the more traditional= approach where the geometric relationship between media streams is not use= d to preserve inter-stream communication aspects such as eye contact and gr= oup dynamics. >=20 > A second difference is manipulation of the environment to improve immersi= on. With telepresence systems, cinematographic aspects of the local enviro= nment reproduction are carefully planned including color, table shape, seat= ing and lighting so that when combined with large high quality displays, a = strong sense of a "trompe l'oeil" or "being there" immersive experience is = created. Typical video conference systems do not include these considerati= ons. >=20 > As telepresence video systems have become successful in the market, manuf= acturers have started exploring delivery of the nonverbal communication and= immersive values of telepresence via smaller, less expensive and more flex= ible video conferencing systems for a variety of venues, such as individual= offices, homes and kiosks. These are also telepresence systems, since the= audio and video quality is high enough to allow clear image reproduction f= or nonverbal communication, they are able to send and receive multiple medi= a streams, and large coordinated multi image displays are available for imm= ersive installations. As the industry develops, the line between telepres= ence and video conferencing may become blurred as nonverbal communication a= nd immersive installations become broadly available. >=20 > Problem > Although telepresence systems are based on open standards such as RTP, SI= P, H.264, H.323 suite, they cannot easily interoperate with each other with= out operator assistance and expensive additional equipment that translates = from one vendor to another. It would be like having to make sure all partie= s are on the same equipment (and network) when making a telephone call. A = major factor in the inability of Telepresence systems to work with each oth= er is that there is no standard description of the multiple streams that co= mprise the media flows. >=20 > For example, in a multiple screen conference, the video and audio streams= sent from remote participants must be understood by receivers so that they= can be presented in a coherent and life-like manner. This includes the abi= lity to present the remote participants at their true size for their appare= nt distance, while maintaining correct eye contact, gesticular cues, and si= multaneously providing a spatial audio sound stage consistent with the vide= o presentation. The receiving device that decides how to display the incom= ing information needs to understand a number of variables such as the spati= al position of the speaker, the field of view of the cameras, the camera zo= om, which media stream is related to each of the displays, etc. >=20 > Charter > The Telepresence Multi-Streams work item in DISPATCH is chartered to defi= ne and specify for SIP-based systems the content of media multi-stream mess= ages and the way these will be transported. >=20 > This work will provide a standard for the exchange of media semantic info= rmation that will foster interoperable end stations and conference bridges.= It will specify variables that describe the semantics of the media stream= s and the recommended behavior to achieve interoperability. >=20 > This requires considering current widely deployed use cases, such as sing= le and multiple screens, multi-point, Scalable Video Coding (SVC), as well = as cases that are expected to be implemented using the protocol framework p= roduced by this work item. The methodology for describing the variables mu= st allow extensibility of the variables, since telepresence is still a youn= g technology and may have use cases that are not currently considered. >=20 > The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media str= eams, including a specification of variables required to support the use ca= ses. This work item will consider the reuse of existing IETF protocols and = produce an architecture/protocol framework document describing the protocol= s required to be implemented to support this functionality. The document w= ill identify any enhancements required to existing protocols as well as des= cribing new protocol(s) for interoperable multi-streams negotiation that ma= y be required. >=20 > Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and FE= Cframe. >=20 > Scope > The scope includes both systems that provide a fully immersive experience= , and systems that interwork with them and therefore need to understand the= same multiple stream semantics. >=20 >=20 > The focus of this work is on audio and video multiple streams. Other med= ia types may be considered, however development of methodologies for them i= s not within the scope of this work. >=20 > Interoperation with standards compliant systems is required, such as SIP-= based video conferencing systems. However, backwards compatibility with ex= isting non-standards compliant telepresence systems is not required. >=20 >=20 >=20 > The group will produce > - Requirements and use cases >=20 > - Architectural Framework describing the protocols required to be impleme= nted to support this functionality and identifying existing protocol enhanc= ements and new protocol functionality required >=20 > - Specification of a new protocol to support telepresence multi-streams [= if required] >=20 > Goals and Milestones > Nov 2010 >=20 >=20 > Use Cases and Requirements to IESG as Informational RFC >=20 > Nov 2010 > March 2011 >=20 > Problem Statement to IESG as Informational RFC > Architecture to IESG as Informational RFC >=20 > March 2011 >=20 > Revise Charter [IF new protocol is not required] >=20 > Nov 2011 >=20 > Submit protocol draft to IESG as Proposed Standard RFC >=20 >=20 >=20 >=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 laura.liess.dt@googlemail.com Wed Jun 9 00:19:58 2010 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 0CDFB3A690C for ; Wed, 9 Jun 2010 00:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: 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-ZiAujG9KVP for ; Wed, 9 Jun 2010 00:19:56 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id CA85E3A6918 for ; Wed, 9 Jun 2010 00:19:54 -0700 (PDT) Received: by wyb32 with SMTP id 32so1378847wyb.31 for ; Wed, 09 Jun 2010 00:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L1JAJII1C7zYIfSirkYUd2UjbphbESeDT3AZ6lRePM4=; b=FIoCnu+4SRdOp3+uesB5+Q5Tqat2Neihnvxzg/Ba8FRB+L6N0DtKPCPUimKlw+oosp cOlLqDHhvNVt/VFyUk1G0xRerXaq3SERzNGkUWssRPMJ7n4s8QCkNALz0JR7IHo/dsd3 x46m10YrgVeG/+gA4vN+TRzGIT0sOtQaTPaHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qpd5j6TebLERbzFL54ofkqem2EL4/t0aL+Evw9Y1d4nXR7LTlOYTxOqD9btoVYHak9 WYSgQi+cVWgqCsATKTYqNnaC3zogFXQ6bd1m0NJ24uiPtxcrV81XwC7vl5G5aDuO13ZI O9bOtIaDuN1o5POWf+/fHVOWlIuCJQOUR+6XU= MIME-Version: 1.0 Received: by 10.216.85.195 with SMTP id u45mr4604336wee.72.1276067989903; Wed, 09 Jun 2010 00:19:49 -0700 (PDT) Received: by 10.216.169.9 with HTTP; Wed, 9 Jun 2010 00:19:49 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 09:19:49 +0200 Message-ID: From: Laura Liess To: Mary Barnes , Gonzalo Camarillo , "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Sparks , DISPATCH Subject: Re: [dispatch] DISPATCH-78 topics 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, 09 Jun 2010 07:19:58 -0000 Hi Mary, Gonzalo, What about the Alert-Info URN? We had a lot of discussion about the charter and name, my opinion was that we had consensus on the charter. Dale would chair the WG. I intend to submit a new draft version by the end of June. I also sent to you an e-mail some time ago asking for a time slot for discussion in Masstricht. Is it anything I missed to do to get agenda time? Thanks a lot Laura 2010/6/8 Mary Barnes : > Hi all, > > Per the reminder posted on the ML on May 4th and as listed on the > DISPATCH WG wiki, charter proposals for the topics to be > handled/dispatched prior to and at IETF-78 were due on May 31st. > > We received charter proposals (problem statements/deliverables) for the > following, with links to most recent charter proposals and discussion thr= eads. > > o Session-ID: =A0updated charter proposal available > http://www.ietf.org/mail-archive/web/dispatch/current/msg01967.html > > o Telepresence: =A0updated charter proposal available > http://www.ietf.org/mail-archive/web/dispatch/current/msg01936.html > > o VIPR: =A0charter proposal > http://www.ietf.org/mail-archive/web/dispatch/current/msg01930.html > > o TEL URI WG proposal: =A0discussion to focus on problem statement and sc= ope > http://www.ietf.org/mail-archive/web/dispatch/current/msg01920.html > > The above items are the current targets for IETF-78 discussions. =A0Based > on those discussions, agenda time will be allocated, items dispatched > and adhocs scheduled as appropriate. Note, that the minimum time we > would allocate to a topic is 30 minutes and some may warrant 45 > minutes. If we schedule adhocs, we will try to have those announced > around the time the agenda is finalized. > > The following items have also been discussed on the mailing list, but > are not yet ready for dispatching: > > o NGN Reason: Some interest. Needs more discussion and scoping. > http://datatracker.ietf.org/doc/draft-jesske-dispatch-reason-in-responses= / > http://datatracker.ietf.org/doc/draft-jesske-dispatch-req-reason-in-respo= nses/ > > o PAN - wait for more energy > http://datatracker.ietf.org/doc/draft-lawrence-sipforum-provider-alias/ > > o =A0ACH - ACH analysis draft to happen as part of BLISS wind down > http://datatracker.ietf.org/doc/draft-ietf-bliss-ach-analysis/ > > o =A0ACH - HTTP API docs - need some hallway discussions > http://datatracker.ietf.org/doc/draft-yusef-dispatch-ach-rest-api/ > > o =A0Media security - needs additional ML discussion > http://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-parameter/ > > o Communication diversion and barring notification - feedback thus far > needs to be considered - i.e, problem statement to be clarified and > alternate solutions to be consider (Note: IPR on the communication > diversion draft) > http://datatracker.ietf.org/doc/draft-avasarala-dispatch-comm-div-notific= ation/ > http://datatracker.ietf.org/doc/-avasarala-dispatch-comm-barring-notifica= tion/ > > > As a reminder, the following are the cutoffs for drafts, so please make > sure that any drafts relevant to the topic are submitted prior to those > deadlines: > * - 00 documents: =A0July 5th (< 4 weeks) > * all other documents: July 12th (< 5 weeks) > > Please keep in mind that the focus of discussions should be the problem > statement, scope and proposed deliverables for the topic. > > As a reminder, items can be dispatched without being discussed at a f2f > meeting and the most effective way to achieve this is to have problem > statements, scope of topics and any relevant documents available for > discussion, rather than documents focusing on solutions. > > Please, let the chairs know if there are any concerns. > > Thanks, > Mary Barnes and Cullen Jennings > DISPATCH WG chairs > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From laura.liess.dt@googlemail.com Wed Jun 9 00:33:06 2010 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 34FB93A6849 for ; Wed, 9 Jun 2010 00:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnRxUyG8ZTuR for ; Wed, 9 Jun 2010 00:33:05 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id E16B43A6907 for ; Wed, 9 Jun 2010 00:33:04 -0700 (PDT) Received: by wwc33 with SMTP id 33so1205971wwc.31 for ; Wed, 09 Jun 2010 00:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oyet/yqEl2bANDn+QSn/tmZnKJuPlmrCsxy3bgnjBSo=; b=TORM8uNf58qdQRo8k6XhVZxw1YPP9m0sx2hhX+IgJXKgAxqXoTrAko1ix47FDhDbJY zHweIA/2a7dfmijVlK30LUsvhdlioLHGHlPXfm5/CB3ghTMddZjQM8PoRHPsBIRluG7F 6JeHt7loOyf1TeF4pYvxvR/qJfqCR5ttK5l9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RQqMMyFNQ3CYeX7wh+qIGrU7LtGtcW4hY2FcXlNZ1HAylFq+Fe19BMO+omPinF89zq tbi+cbx69p6FLltXUIg4YiKjouYPx4+Sxg5u1DY+SA6f/TmNjXXTRp64Ss6ALSFbvTWq IL7h3Vs9qL12Oc2TB/CL1CpCvizSLpHw6nZjc= MIME-Version: 1.0 Received: by 10.227.156.5 with SMTP id u5mr7103229wbw.27.1276068779574; Wed, 09 Jun 2010 00:32:59 -0700 (PDT) Received: by 10.216.169.9 with HTTP; Wed, 9 Jun 2010 00:32:59 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> Date: Wed, 9 Jun 2010 09:32:59 +0200 Message-ID: From: Laura Liess To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Final Charter for Session-ID? 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, 09 Jun 2010 07:33:06 -0000 +1 I think the charter is consistent to what is needed in the field. Thanks Laura 2010/6/7 Hadriel Kaplan : > > Howdy, > I have heard no objections to this version of the charter (other than a d= ebate about how to solve it). > If you have any comments regarding the charter, please speak now. =A0Than= ks! > > -hadriel > > > SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPS= COTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a mechanism that allow= s operators and monitoring equipment to correlate SIP messages and dialogs = of the same higher-level end-to-end "session" across multiple SIP device ho= ps for the same "message-flow", for the purpose of troubleshooting. =A0In p= articular, the mechanism must be able to allow such correlation across SIP = B2BUAs of as many functional types as possible, such as Application Servers= , Softswitches, PBXs, SBCs, etc. > > The definition of a higher-layer "session" of the same "message-flow" is = not defined by SIP when it involves a B2BUA, and is difficult to normativel= y define in practice. =A0For the purposes of this WG charter's scope, two o= r more dialogs of a B2BUA are correlated under any conditions where correla= tion might aid troubleshooting, by identifying them as belonging to the sam= e higher-level session. =A0Any solution documents from this working group m= ay expand or constrain the scope of their mechanism's correlation, if the w= orking group so decides. > > Although other solutions may be possible, this working group will focus o= n defining a new SIP Header field for such a purpose, similar to the Call-I= D header field, in order to provide a simple, easily deployable mechanism w= hich can work across SIP domains. The SIP Call-ID header field value itself= is not usable for such correlation, because many B2BUAs must create a new = Call-ID value on their UAC "side" in order to function properly, and to com= ply with the rules of RFC 3261. > > It should be noted that certain SIP B2BUAs perform a "topology-hiding" fu= nction, as described in RFC 5853. =A0The working group will take such funct= ions into account for the correlation mechanism, as well as provide guidanc= e for implementers of the mechanism to avoid triggering such a function for= the mechanism's header field value. > > Lastly, although in certain environments such a mechanism may be usable f= or dialog correlation in SIP state machines, it is not the goal of this wor= king group to address that usage. > > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dec 2010 - New header specification to IESG (PS) > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From laura.liess.dt@googlemail.com Wed Jun 9 00:34:54 2010 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 8E17A28C0CF for ; Wed, 9 Jun 2010 00:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjn4AK5zRHAv for ; Wed, 9 Jun 2010 00:34:54 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AB73C28B23E for ; Wed, 9 Jun 2010 00:34:53 -0700 (PDT) Received: by wwc33 with SMTP id 33so1206956wwc.31 for ; Wed, 09 Jun 2010 00:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dZpPO1I5bc2n9WPRslSt5wcfygyAybPE7RoQGQYRh8I=; b=Ix2q3n4zPVTrNg/uEpHA+wG3mwZMAzQwsTIoutGvNxhxrezg7Fczn5hgufXwZ5jqCy /yjtEL2kY5d9uNWYhBnnS3ZP/9vEAze93Ta//b6HSb0FV7GBkoH8ppuR65g1hjtSLhsI x6ro5vYqPeaNGXUJebn35Y4m1dvePq97ABUCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bEWZxnBh5GlkI8xfVjWXRGrYGsTR//qB0mAcVXtA084sSeBT9epxT+tIA6NDAkshuS ELIKOUdF+iRj9Cyu7YotlGiICqoOiQP5EvCO71I4iOcrCGTL8QCt068Ok/HRXTHtnj44 ncVEokgkseaHcRyvUsH2ZVPe00o2zo7lQs+TY= MIME-Version: 1.0 Received: by 10.216.86.16 with SMTP id v16mr4602820wee.111.1276068890358; Wed, 09 Jun 2010 00:34:50 -0700 (PDT) Received: by 10.216.169.9 with HTTP; Wed, 9 Jun 2010 00:34:50 -0700 (PDT) In-Reply-To: <348C248A-064E-48D9-AAE7-04A9561D16D7@cisco.com> References: <4BF3F281.8080102@ericsson.com> <4BF4E72B.7060600@ericsson.com> <348C248A-064E-48D9-AAE7-04A9561D16D7@cisco.com> Date: Wed, 9 Jun 2010 09:34:50 +0200 Message-ID: From: Laura Liess To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH Subject: Re: [dispatch] Alert Info URNs - Acronym 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, 09 Jun 2010 07:34:54 -0000 I am OK with both, too. Thanks Laura 2010/6/2 Cullen Jennings : > > +1 to ALES or SALUD > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From victor.pascual.avila@gmail.com Wed Jun 9 02:26:13 2010 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 F2F0828C0FA for ; Wed, 9 Jun 2010 02:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSzTu70ynvJN for ; Wed, 9 Jun 2010 02:26:12 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id F191C28C0E8 for ; Wed, 9 Jun 2010 02:26:11 -0700 (PDT) Received: by bwz6 with SMTP id 6so584899bwz.31 for ; Wed, 09 Jun 2010 02:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rtCt4R8y61Wz0zt/3uYoVqxpvFuLL3TLNws8XbL79HA=; b=l92mhaNytyq4JMah74E2oScuwDjiRbG420DvVqRxXem3MjL/KO4jQ1ZFz6hEwEJF07 32i+vQT+00OMdC/BfZoRH8um7CObPsmpyDNEvIKsq3gcFeIfE5lU7sChwPWm9e8KD27Z M+frNjz0jAQnb5qFxsJPq3ARJFPCXQ7LNdbMk= 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:content-transfer-encoding; b=Fg/CKMJlNHY+9jk2Z9OB/i5IhUFurdfnrwkGWAR2fiBM08S7UEHoBryY4XfQA90lh5 wcKgnzLgNcCYR8BenN0cpoRz81qx9cA5oquzFEXR2I0sI99Rlbw+gH4udozpizwziucb lE/dPNZhNzrbjs1mEPSQbD8Pjzfil+aYAx+xs= MIME-Version: 1.0 Received: by 10.204.9.150 with SMTP id l22mr1498887bkl.197.1276075570311; Wed, 09 Jun 2010 02:26:10 -0700 (PDT) Received: by 10.204.70.141 with HTTP; Wed, 9 Jun 2010 02:26:10 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> Date: Wed, 9 Jun 2010 11:26:10 +0200 Message-ID: From: Victor Pascual Avila To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Final Charter for Session-ID? 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, 09 Jun 2010 09:26:13 -0000 On Mon, Jun 7, 2010 at 3:51 PM, Hadriel Kaplan wro= te: > > Howdy, > I have heard no objections to this version of the charter (other than a d= ebate about how to solve it). > If you have any comments regarding the charter, please speak now. =C2=A0T= hanks! I'm fine with this charter, it's addressing a real problem and the scope is clear. Cheers, --=20 Victor Pascual =C3=81vila From peter.musgrave@magorcorp.com Wed Jun 9 02:47:16 2010 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 B95B43A6956 for ; Wed, 9 Jun 2010 02:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh1wO+baEndO for ; Wed, 9 Jun 2010 02:47:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B08003A6933 for ; Wed, 9 Jun 2010 02:47:08 -0700 (PDT) Received: by vws9 with SMTP id 9so1329857vws.31 for ; Wed, 09 Jun 2010 02:47:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.123.156 with SMTP id p28mr1838401qar.152.1276076825596; Wed, 09 Jun 2010 02:47:05 -0700 (PDT) Received: by 10.229.217.16 with HTTP; Wed, 9 Jun 2010 02:47:05 -0700 (PDT) In-Reply-To: References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> Date: Wed, 9 Jun 2010 05:47:05 -0400 Message-ID: From: Peter Musgrave To: Victor Pascual Avila Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] Final Charter for Session-ID? 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, 09 Jun 2010 09:47:16 -0000 I'd like to see this go forward too. Peter On Wed, Jun 9, 2010 at 5:26 AM, Victor Pascual Avila wrote: > On Mon, Jun 7, 2010 at 3:51 PM, Hadriel Kaplan w= rote: >> >> Howdy, >> I have heard no objections to this version of the charter (other than a = debate about how to solve it). >> If you have any comments regarding the charter, please speak now. =A0Tha= nks! > > I'm fine with this charter, it's addressing a real problem and the > scope is clear. > > Cheers, > -- > Victor Pascual =C1vila > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dyork@voxeo.com Wed Jun 9 05:24:02 2010 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 643A13A6966 for ; Wed, 9 Jun 2010 05:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQFfpy8ScJQU for ; Wed, 9 Jun 2010 05:24:01 -0700 (PDT) Received: from hiltoncluster2.worldspice.net (hiltoncluster2.worldspice.net [216.37.94.62]) by core3.amsl.com (Postfix) with ESMTP id 25B563A691C for ; Wed, 9 Jun 2010 05:24:00 -0700 (PDT) Received: (qmail 14141 invoked by uid 0); 9 Jun 2010 12:24:01 -0000 Received: by simscan 1.4.0 ppid: 12617, pid: 14011, t: 4.0126s scanners: clamav: 0.95.3/m:51/d:10354 spam: 3.3.0 Received: from unknown (HELO ?172.28.172.62?) (12.189.115.2) by hiltoncluster02.worldspice.net with SMTP; 9 Jun 2010 12:23:57 -0000 References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> Message-Id: <595F86FA-BA2C-4D07-A154-67CC7F076486@voxeo.com> From: Dan York To: Peter Musgrave In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 7B367) Date: Wed, 9 Jun 2010 06:42:50 -0400 X-Mailer: iPad Mail (7B367) Cc: "dispatch@ietf.org" , Hadriel Kaplan Subject: Re: [dispatch] Final Charter for Session-ID? 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, 09 Jun 2010 12:24:02 -0000 +1 -- Dan York http://www.voxeo.com/ http://blogs.voxeo.com/ http://www.danyork.com/ http://twitter.com/danyork On Jun 9, 2010, at 5:47 AM, Peter Musgrave = wrote: > I'd like to see this go forward too. >=20 > Peter >=20 > On Wed, Jun 9, 2010 at 5:26 AM, Victor Pascual Avila > wrote: >> On Mon, Jun 7, 2010 at 3:51 PM, Hadriel Kaplan = wrote: >>>=20 >>> Howdy, >>> I have heard no objections to this version of the charter (other = than a debate about how to solve it). >>> If you have any comments regarding the charter, please speak now. = Thanks! >>=20 >> I'm fine with this charter, it's addressing a real problem and the >> scope is clear. >>=20 >> Cheers, >> -- >> Victor Pascual =C3=81vila >> _______________________________________________ >> 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 dschwartz@xconnect.net Wed Jun 9 05:26:36 2010 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 302043A690C for ; Wed, 9 Jun 2010 05:26: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 ElPVsCXfbYmL for ; Wed, 9 Jun 2010 05:26:35 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id CA0223A6905 for ; Wed, 9 Jun 2010 05:26:34 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Wed, 9 Jun 2010 15:26:33 +0300 From: David Schwartz To: "dispatch@ietf.org" Date: Wed, 9 Jun 2010 15:25:38 +0300 Thread-Topic: [dispatch] Final Charter for Session-ID? Thread-Index: AcsHzqn3lwz6cW2SQeOld/inbaxTqwAADQUJ Message-ID: <6EA53FAD386F9D46B97D49BFE148D51436A60797@ISR-JLM-MAIL1.xconnect.co.il> References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> , <595F86FA-BA2C-4D07-A154-67CC7F076486@voxeo.com> In-Reply-To: <595F86FA-BA2C-4D07-A154-67CC7F076486@voxeo.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hadriel Kaplan Subject: Re: [dispatch] Final Charter for Session-ID? 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, 09 Jun 2010 12:26:36 -0000 +1 > On Wed, Jun 9, 2010 at 5:26 AM, Victor Pascual Avila > wrote: >> On Mon, Jun 7, 2010 at 3:51 PM, Hadriel Kaplan = wrote: >>> >>> Howdy, >>> I have heard no objections to this version of the charter (other than a= debate about how to solve it). >>> If you have any comments regarding the charter, please speak now. Than= ks! >> >> I'm fine with this charter, it's addressing a real problem and the >> scope is clear. >> >> Cheers, >> -- >> Victor Pascual =C1vila >> _______________________________________________ >> 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 fluffy@cisco.com Wed Jun 9 07:53:30 2010 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 E37E63A6988 for ; Wed, 9 Jun 2010 07:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.601 X-Spam-Level: X-Spam-Status: No, score=-108.601 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 SriS92pYLSpJ for ; Wed, 9 Jun 2010 07:53:29 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DD7E33A697F for ; Wed, 9 Jun 2010 07:53:29 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC1ID0yrR7H+/2dsb2JhbACeSHGkEZoQhRgEg0k X-IronPort-AV: E=Sophos;i="4.53,391,1272844800"; d="scan'208";a="141731509" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 09 Jun 2010 14:53:31 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o59ErQBG019051 for ; Wed, 9 Jun 2010 14:53:31 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> Date: Wed, 9 Jun 2010 08:53:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> To: DISPATCH list X-Mailer: Apple Mail (2.1078) Subject: Re: [dispatch] Final Charter for Session-ID? 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, 09 Jun 2010 14:53:31 -0000 I have a problem with this proposed charter.=20 On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: >=20 > The definition of a higher-layer "session" of the same "message-flow" = is not defined by SIP when it involves a B2BUA, and is difficult to = normatively define in practice. For the purposes of this WG charter's = scope, two or more dialogs of a B2BUA are correlated under any = conditions where correlation might aid troubleshooting, by identifying = them as belonging to the same higher-level session. Any solution = documents from this working group may expand or constrain the scope of = their mechanism's correlation, if the working group so decides. I think the above text is way too vague and impossible to reduce to = engineering practice. If you have 10 calls going to a PSTN GWs that is = having voice quality problems, clearly having all of them grouped = together is useful in debugging. Yet I doubt we want all the calls from = a given PSTN GW to have the same correlation ID. Our lack of any solid = definition of what it is we are trying to correlate is a strong = indication to me that we have not yet come to any consensus about what = the problem is this WG would be trying to fix. =20 I would like to see a WG charted in this area but I would expect the = IESG to more or less laugh at a problem statement that reduced down to = "uh might be useful for debuggin". Can some people please try and = propose a more concrete definition of when two sip dialogs will be = correlated? Cullen From mary.ietf.barnes@gmail.com Wed Jun 9 10:13:14 2010 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 AC8633A69C1 for ; Wed, 9 Jun 2010 10:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, 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 ycaKcK9m-10m for ; Wed, 9 Jun 2010 10:13:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6112A3A69C0 for ; Wed, 9 Jun 2010 10:13:12 -0700 (PDT) Received: by iwn42 with SMTP id 42so6001918iwn.31 for ; Wed, 09 Jun 2010 10:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=fDe+O+sJS2eqcb1jQmkLJprAp09JjR+NP3HVIAeOXsI=; b=Z54N3ztBBKbyjnup7x1tUZ4FPodCTHaqbzLxNzxNt6t88Xhn1zZN4qOfItEm1BwnU1 +4HgKNlGs/tqt2ikDR4RCy0Upp1RszJmKpn4HVHbtZmrTkjubJWuHAHPKPkxuBLsTxZb UV3IFFaA3Gl/j1c+QvTrtHZK3gjVKDRR8Hbec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=det+Qg/I11Tg7vg4liMJEr4ngzAI694OwqUdS8Yu4uQ0rca4EUOb+MZ/5Sml6COenW uxZfmk1A/9Jjv8W9FHZS9R2hByYh+ojiQlMaEP/aUmsafPfuyWqXstrbEJhWF+3n9nBH c2NE1mdcXNZsExZtBYVMV7ZlE1Huu8RN7h4TA= MIME-Version: 1.0 Received: by 10.231.150.1 with SMTP id w1mr3211872ibv.7.1276103591233; Wed, 09 Jun 2010 10:13:11 -0700 (PDT) Received: by 10.231.145.146 with HTTP; Wed, 9 Jun 2010 10:13:11 -0700 (PDT) Date: Wed, 9 Jun 2010 12:13:11 -0500 Message-ID: From: Mary Barnes To: Laura Liess Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Sparks , DISPATCH , Gonzalo Camarillo Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs 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, 09 Jun 2010 17:13:14 -0000 Hi Laura, We did not consider this topic for pre-IETF-78 focus for the DISPATCH WG because the ADs are already in the process of preparing the charter for approval by the IESG, as I understood Gonzalo's emails on the topic. I'll let ADs discuss the timeline for the chartering and really it would be up to them as to whether a meeting agenda slot would be requested for the topic. The current model we've been using is that past topics that have been agreed to be chartered have already been "dispatched" per se, per the summaries in the wiki: http://trac.tools.ietf.org/wg/dispatch/trac/wiki Thanks, Mary. On Wed, Jun 9, 2010 at 2:19 AM, Laura Liess wrote: > Hi Mary, Gonzalo, > > What about the Alert-Info URN? =A0We had a lot of discussion about the > charter and name, my opinion was that we had consensus on the charter. > Dale would chair the WG. =A0I intend to submit a new draft version by > the end of June. > I also sent to you an e-mail some time ago asking for a time slot for > discussion in Masstricht. Is it anything I missed to do to get agenda > time? > > Thanks a lot > Laura > > > > > 2010/6/8 Mary Barnes : >> Hi all, >> >> Per the reminder posted on the ML on May 4th and as listed on the >> DISPATCH WG wiki, charter proposals for the topics to be >> handled/dispatched prior to and at IETF-78 were due on May 31st. >> >> We received charter proposals (problem statements/deliverables) for the >> following, with links to most recent charter proposals and discussion th= reads. >> >> o Session-ID: =A0updated charter proposal available >> http://www.ietf.org/mail-archive/web/dispatch/current/msg01967.html >> >> o Telepresence: =A0updated charter proposal available >> http://www.ietf.org/mail-archive/web/dispatch/current/msg01936.html >> >> o VIPR: =A0charter proposal >> http://www.ietf.org/mail-archive/web/dispatch/current/msg01930.html >> >> o TEL URI WG proposal: =A0discussion to focus on problem statement and s= cope >> http://www.ietf.org/mail-archive/web/dispatch/current/msg01920.html >> >> The above items are the current targets for IETF-78 discussions. =A0Base= d >> on those discussions, agenda time will be allocated, items dispatched >> and adhocs scheduled as appropriate. Note, that the minimum time we >> would allocate to a topic is 30 minutes and some may warrant 45 >> minutes. If we schedule adhocs, we will try to have those announced >> around the time the agenda is finalized. >> >> The following items have also been discussed on the mailing list, but >> are not yet ready for dispatching: >> >> o NGN Reason: Some interest. Needs more discussion and scoping. >> http://datatracker.ietf.org/doc/draft-jesske-dispatch-reason-in-response= s/ >> http://datatracker.ietf.org/doc/draft-jesske-dispatch-req-reason-in-resp= onses/ >> >> o PAN - wait for more energy >> http://datatracker.ietf.org/doc/draft-lawrence-sipforum-provider-alias/ >> >> o =A0ACH - ACH analysis draft to happen as part of BLISS wind down >> http://datatracker.ietf.org/doc/draft-ietf-bliss-ach-analysis/ >> >> o =A0ACH - HTTP API docs - need some hallway discussions >> http://datatracker.ietf.org/doc/draft-yusef-dispatch-ach-rest-api/ >> >> o =A0Media security - needs additional ML discussion >> http://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-parameter/ >> >> o Communication diversion and barring notification - feedback thus far >> needs to be considered - i.e, problem statement to be clarified and >> alternate solutions to be consider (Note: IPR on the communication >> diversion draft) >> http://datatracker.ietf.org/doc/draft-avasarala-dispatch-comm-div-notifi= cation/ >> http://datatracker.ietf.org/doc/-avasarala-dispatch-comm-barring-notific= ation/ >> >> >> As a reminder, the following are the cutoffs for drafts, so please make >> sure that any drafts relevant to the topic are submitted prior to those >> deadlines: >> * - 00 documents: =A0July 5th (< 4 weeks) >> * all other documents: July 12th (< 5 weeks) >> >> Please keep in mind that the focus of discussions should be the problem >> statement, scope and proposed deliverables for the topic. >> >> As a reminder, items can be dispatched without being discussed at a f2f >> meeting and the most effective way to achieve this is to have problem >> statements, scope of topics and any relevant documents available for >> discussion, rather than documents focusing on solutions. >> >> Please, let the chairs know if there are any concerns. >> >> Thanks, >> Mary Barnes and Cullen Jennings >> DISPATCH WG chairs >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From mperumal@cisco.com Wed Jun 9 23:07:55 2010 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 953B33A69F1 for ; Wed, 9 Jun 2010 23:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjF1StTU4NH3 for ; Wed, 9 Jun 2010 23:07:54 -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 8A9723A69F0 for ; Wed, 9 Jun 2010 23:07:54 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOMdEExAaHte/2dsb2JhbACeZnGjQZonhRgEg0k X-IronPort-AV: E=Sophos;i="4.53,396,1272844800"; d="scan'208";a="260828732" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 10 Jun 2010 06:07:53 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5A67pgJ014707 for ; Thu, 10 Jun 2010 06:07:53 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 11:37:22 +0530 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, 10 Jun 2010 11:37:20 +0530 Message-ID: <1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Final Charter for Session-ID? Thread-Index: AcsH46YldzuQEHuJTV6XKso2dlhwhgAfSYWA References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Cullen Jennings (fluffy)" , "DISPATCH list" X-OriginalArrivalTime: 10 Jun 2010 06:07:22.0705 (UTC) FILETIME=[30FFDC10:01CB0863] Subject: Re: [dispatch] Final Charter for Session-ID? 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, 10 Jun 2010 06:07:55 -0000 Here is an initial attempt: If there is a dialog between A and B then A and B are in a session. If there is a dialog between A and B and a dialog between B and C at the same time then A, B and C are in a session. More generally, if two or more participants are part of a session S and at the same time there is a dialog between one of the participants of S and another participant Z who is not part of S, then S (union) Z is a session. I think this would cover most of SBC, 3PCC an app server cases. People can add cases like park/retrieve if they think they should be considered as part of a single session. Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf |Of Cullen Jennings (fluffy) |Sent: Wednesday, June 09, 2010 8:23 PM |To: DISPATCH list |Subject: Re: [dispatch] Final Charter for Session-ID? | |I have a problem with this proposed charter. | |On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: | |> |> The definition of a higher-layer "session" of the same "message-flow" is |not defined by SIP when it involves a B2BUA, and is difficult to normatively |define in practice. For the purposes of this WG charter's scope, two or |more dialogs of a B2BUA are correlated under any conditions where |correlation might aid troubleshooting, by identifying them as belonging to |the same higher-level session. Any solution documents from this working |group may expand or constrain the scope of their mechanism's correlation, if |the working group so decides. | |I think the above text is way too vague and impossible to reduce to |engineering practice. If you have 10 calls going to a PSTN GWs that is |having voice quality problems, clearly having all of them grouped together |is useful in debugging. Yet I doubt we want all the calls from a given PSTN |GW to have the same correlation ID. Our lack of any solid definition of what |it is we are trying to correlate is a strong indication to me that we have |not yet come to any consensus about what the problem is this WG would be |trying to fix. | |I would like to see a WG charted in this area but I would expect the IESG to |more or less laugh at a problem statement that reduced down to "uh might be |useful for debuggin". Can some people please try and propose a more concrete |definition of when two sip dialogs will be correlated? | |Cullen | |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From L.Liess@telekom.de Wed Jun 9 23:11:56 2010 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 4DA713A68CF for ; Wed, 9 Jun 2010 23:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0x9P-t9ur3HN for ; Wed, 9 Jun 2010 23:11:55 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 62C2B3A6888 for ; Wed, 9 Jun 2010 23:11:54 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 10 Jun 2010 08:11:46 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 08:11:41 +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, 10 Jun 2010 08:11:39 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A004586080@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] DISPATCH-78 topics - Alert URNs Thread-Index: AcsH9xMRwYAcjGeeTNqDbYp7kJctbAAbJg8g References: From: To: , X-OriginalArrivalTime: 10 Jun 2010 06:11:41.0004 (UTC) FILETIME=[CAF528C0:01CB0863] Cc: RjS@nostrum.com, dispatch@ietf.org, gonzalo.camarillo@ericsson.com Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs 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, 10 Jun 2010 06:11:56 -0000 Hi Mary, Thanks a lot. Laura =20 >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >Sent: Wednesday, June 09, 2010 7:13 PM >To: Laura Liess >Cc: Robert Sparks; DISPATCH; Gonzalo Camarillo >Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs > >Hi Laura, > >We did not consider this topic for pre-IETF-78 focus for the DISPATCH >WG because the ADs are already in the process of preparing the charter >for approval by the IESG, as I understood Gonzalo's emails on the >topic. I'll let ADs discuss the timeline for the chartering and >really it would be up to them as to whether a meeting agenda slot >would be requested for the topic. > >The current model we've been using is that past topics that have been >agreed to be chartered have already been "dispatched" per se, per the >summaries in the wiki: >http://trac.tools.ietf.org/wg/dispatch/trac/wiki > >Thanks, >Mary. > > > > >On Wed, Jun 9, 2010 at 2:19 AM, Laura Liess > wrote: >> Hi Mary, Gonzalo, >> >> What about the Alert-Info URN? =A0We had a lot of discussion about = the >> charter and name, my opinion was that we had consensus on=20 >the charter. >> Dale would chair the WG. =A0I intend to submit a new draft version by >> the end of June. >> I also sent to you an e-mail some time ago asking for a time slot for >> discussion in Masstricht. Is it anything I missed to do to get agenda >> time? >> >> Thanks a lot >> Laura >> >> >> >> >> 2010/6/8 Mary Barnes : >>> Hi all, >>> >>> Per the reminder posted on the ML on May 4th and as listed on the >>> DISPATCH WG wiki, charter proposals for the topics to be >>> handled/dispatched prior to and at IETF-78 were due on May 31st. >>> >>> We received charter proposals (problem=20 >statements/deliverables) for the >>> following, with links to most recent charter proposals and=20 >discussion threads. >>> >>> o Session-ID: =A0updated charter proposal available >>> http://www.ietf.org/mail-archive/web/dispatch/current/msg01967.html >>> >>> o Telepresence: =A0updated charter proposal available >>> http://www.ietf.org/mail-archive/web/dispatch/current/msg01936.html >>> >>> o VIPR: =A0charter proposal >>> http://www.ietf.org/mail-archive/web/dispatch/current/msg01930.html >>> >>> o TEL URI WG proposal: =A0discussion to focus on problem=20 >statement and scope >>> http://www.ietf.org/mail-archive/web/dispatch/current/msg01920.html >>> >>> The above items are the current targets for IETF-78=20 >discussions. =A0Based >>> on those discussions, agenda time will be allocated, items=20 >dispatched >>> and adhocs scheduled as appropriate. Note, that the minimum time we >>> would allocate to a topic is 30 minutes and some may warrant 45 >>> minutes. If we schedule adhocs, we will try to have those announced >>> around the time the agenda is finalized. >>> >>> The following items have also been discussed on the mailing=20 >list, but >>> are not yet ready for dispatching: >>> >>> o NGN Reason: Some interest. Needs more discussion and scoping. >>>=20 >http://datatracker.ietf.org/doc/draft-jesske-dispatch-reason-in >-responses/ >>>=20 >http://datatracker.ietf.org/doc/draft-jesske-dispatch-req-reaso n-in-responses/ >>> >>> o PAN - wait for more energy >>>=20 >http://datatracker.ietf.org/doc/draft-lawrence-sipforum-provider-alias/ >>> >>> o =A0ACH - ACH analysis draft to happen as part of BLISS wind down >>> http://datatracker.ietf.org/doc/draft-ietf-bliss-ach-analysis/ >>> >>> o =A0ACH - HTTP API docs - need some hallway discussions >>> http://datatracker.ietf.org/doc/draft-yusef-dispatch-ach-rest-api/ >>> >>> o =A0Media security - needs additional ML discussion >>>=20 >http://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-p arameter/ >>> >>> o Communication diversion and barring notification -=20 >feedback thus far >>> needs to be considered - i.e, problem statement to be clarified and >>> alternate solutions to be consider (Note: IPR on the communication >>> diversion draft) >>>=20 >http://datatracker.ietf.org/doc/draft-avasarala-dispatch-comm-d iv-notification/ >>>=20 >http://datatracker.ietf.org/doc/-avasarala-dispatch-comm-barrin g-notification/ >>> >>> >>> As a reminder, the following are the cutoffs for drafts, so=20 >please make >>> sure that any drafts relevant to the topic are submitted=20 >prior to those >>> deadlines: >>> * - 00 documents: =A0July 5th (< 4 weeks) >>> * all other documents: July 12th (< 5 weeks) >>> >>> Please keep in mind that the focus of discussions should be=20 >the problem >>> statement, scope and proposed deliverables for the topic. >>> >>> As a reminder, items can be dispatched without being=20 >discussed at a f2f >>> meeting and the most effective way to achieve this is to=20 >have problem >>> statements, scope of topics and any relevant documents available for >>> discussion, rather than documents focusing on solutions. >>> >>> Please, let the chairs know if there are any concerns. >>> >>> Thanks, >>> Mary Barnes and Cullen Jennings >>> DISPATCH WG 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 Peter.Dawes@vodafone.com Thu Jun 10 02:51:30 2010 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 77F4B3A6A01 for ; Thu, 10 Jun 2010 02:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 3PMw3IacfXMj for ; Thu, 10 Jun 2010 02:51:29 -0700 (PDT) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by core3.amsl.com (Postfix) with ESMTP id AB67A3A6947 for ; Thu, 10 Jun 2010 02:51:28 -0700 (PDT) Received: from mailint02 (localhost [127.0.0.1]) by mailout02 (Postfix) with ESMTP id C3626214BCC for ; Thu, 10 Jun 2010 11:51:27 +0200 (CEST) Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint02 (Postfix) with ESMTPS id B4FEC214BC5; Thu, 10 Jun 2010 11:51:27 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 11:51:28 +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, 10 Jun 2010 11:51:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [dispatch] Final Charter for Session-ID? Thread-Index: AcsIgojlqut4YEMTR9iCbYzMOxUGOQ== From: "Dawes, Peter, VF-Group" To: X-OriginalArrivalTime: 10 Jun 2010 09:51:28.0700 (UTC) FILETIME=[7F6FDFC0:01CB0882] Cc: HKaplan@acmepacket.com Subject: Re: [dispatch] Final Charter for Session-ID? 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, 10 Jun 2010 09:51:30 -0000 Hello All, I agree with Cullen in that the implementer of a B2BUA will need more = guidance than is in the proposed charter now in order to decide whether = dialogs are related, but I think the first question is how much of this = guidance goes in the charter and how much in the working group drafts. It might help to consider what it means for a UA to provide a = correlation header field (e.g. session-ID) at dialog setup. Using the = transfer case from Paul below: >> A ----------- B ----------- C >> | >> |------------ D If A adds a session-ID header field, then it means that A is interested = in the successful functioning of this session, and B2BUA B has this = knowledge when it receives an INVITE from A containing the session-ID = header field. At transfer of C to D, the session-ID value shall be the = same since A is still in the session. If the transfer is done by D = sending an INVITE, then B2BUA B can insert the session-ID. I don't think = it matters that D doesn't put the session-ID header field in its INVITE = request since correlation is interested in what happens to A, not in the = ability of D to enter a session or the ability of C to transfer a = session. Regarding the wording of the charter, I think only one of the two = undefined terms "higher-layer session" and "message-flow" should be used = (i.e. replace "higher-layer session" with "message-flow" or vice versa). A possible revision of the charter text is below. Regards, Peter SIP Signaling-COmmunication Troubleshooting with Correlation Header = (SIPSCOTCH) Charter: ---------------------------------- The SIPSCOTCH working group is chartered to define a mechanism that = allows operators and monitoring equipment to correlate multiple SIP = messages and dialogs across multiple SIP device hops for the purpose of = troubleshooting in the case when such messages or dialogs provide a single communication experience for a single user. A single user may = be network entity such as a SIP B2BUA, PBX, Softswitch, etc.=A0In particular, the mechanism must be able to allow = such correlation across SIP B2BUAs of as many functional types as = possible, such as Application Servers, Softswitches, PBXs, SBCs, etc. For the purposes of this WG charter's scope, two or more dialogs of a = B2BUA are correlated under any conditions where correlation might aid = troubleshooting, by identifying them as providing a single = communication experience to a single user. A correlation identifier will = be duplicated in each dialog that impacts the communication experience = of the user agent that provided that correlation identifier. Any = solution documents from this working group may expand or constrain the = scope of their mechanism's correlation, if the working group so decides. Although other solutions may be possible, this working group will focus = on defining a new SIP Header field for such a purpose, similar to the = Call-ID header field, in order to provide a simple, easily deployable = mechanism which can work across SIP domains. The SIP Call-ID header = field value itself is not usable for such correlation, because many = B2BUAs must create a new Call-ID value on their UAC "side" in order to = function properly, and to comply with the rules of RFC 3261. It should be noted that certain SIP B2BUAs perform a "topology-hiding" = function, as described in RFC 5853. =A0The working group will take such = functions into account for the correlation mechanism, as well as = provide guidance for implementers of the mechanism to avoid triggering = such a function for the mechanism's header field value. Lastly, although in certain environments such a mechanism may be usable = for dialog correlation in SIP state machines, it is not the goal of this = working group to address that usage. -------------------------------------------------------------------------= - I have a problem with this proposed charter.=20 On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: >=20 > The definition of a higher-layer "session" of the same "message-flow" = is not defined by SIP when it involves a B2BUA, and is difficult to = normatively define in practice. For the purposes of this WG charter's = scope, two or more dialogs of a B2BUA are correlated under any = conditions where correlation might aid troubleshooting, by identifying = them as belonging to the same higher-level session. Any solution = documents from this working group may expand or constrain the scope of = their mechanism's correlation, if the working group so decides. I think the above text is way too vague and impossible to reduce to = engineering practice. If you have 10 calls going to a PSTN GWs that is = having voice quality problems, clearly having all of them grouped = together is useful in debugging. Yet I doubt we want all the calls from = a given PSTN GW to have the same correlation ID. Our lack of any solid = definition of what it is we are trying to correlate is a strong = indication to me that we have not yet come to any consensus about what = the problem is this WG would be trying to fix. =20 I would like to see a WG charted in this area but I would expect the = IESG to more or less laugh at a problem statement that reduced down to = "uh might be useful for debuggin". Can some people please try and = propose a more concrete definition of when two sip dialogs will be = correlated? Cullen Message: 5 Date: Sat, 15 May 2010 00:00:37 -0400 From: Paul Kyzivat Subject: Re: [dispatch] Proposed update to Session-ID charter, round-4 To: Hadriel Kaplan Cc: DISPATCH Message-ID: <4BEE1C65.1090507@cisco.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Hadriel, I don't disagree with anything you say below. But it is also what is troubling to me. It seems there is no one obvious definition for which dialogs should be = related - there are good reasons for each of several possible = definitions. Yet its hard to imagine supporting them all. And leaving it = to the discretion of each server seems even worse. So I don't see how to = decide on a definition. Thanks, Paul Hadriel Kaplan wrote: >=20 >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, May 14, 2010 7:56 PM >> >> Hadriel Kaplan wrote: >>> For media-based sessions, such B2BUA's actually can and do represent >> different media sources at different points in the call; for example=20 >> app servers which generate specific tones/music to the UAC while they = >> hunt for the called party. >> >> I find very little difference between this scenario and one where the = >> call is first answered by a secretary and then transferred to the=20 >> intended callee. (Does it matter that the secretary is automated?) >=20 > In the case I was describing, the first dialog leg doesn't reach an = established state until the party is found. If it *did*, which happens = in some find-me-follow-me app servers, then I would think they're really = separate session-ids. I'm not super-tide to that position, just seems = logical to me for some reason. >=20 > =20 >> I'm a bit confused about how things should work if the transfer case=20 >> does *not* share the same session-id: >> >> A ----------- B ----------- C >> | >> |------------ D >> >> Initially from A via B2BUA B to C, and gets Session-ID X applied to=20 >> both the A-B leg and the B-C leg. Then B replaces the B-C "leg" with=20 >> the B-D "leg". If the B-D leg doesn't get session-id X, and instead=20 >> gets session-ID Y, does A-B then also get a new session-id of Y??? It = >> seems it must if the correlation is to work for that. >> That then means that a single dialog, A-B has more than one = session-id: >> X and Y. Is that what is intended??? >=20 > In the current Session-ID draft, it makes no statement about that, = iirc. =20 > I think that's one of the things the SIPSCOTCH WG must decide: whether = A-B-D is in fact the same session-id as A-B-C. If it *is*, then I'd = argue a transferred call from A directly to D, replacing A-B-C, is also = the same session-id. >=20 > I can see it both ways. Arguably, if A-B-C got to the established = state, that was higher-layer Call-1. If B-C gets replaced with B-D, = then A-B-D is Call-2. On the other hand, from a troubleshooting = perspective it would be nice to know those dialogs are all related. >=20 > Note that once you open the door for the session-id to go beyond the = initial established call, it can get weird and complicated. >=20 > For example, what happens if you call a public-announcement = broadcaster server; you press some special codes, record an = announcement, and press "broadcast"; do the sessions it creates for you = use the same session-id as your call? >=20 > Or take your example above, B-D could have replaced B-C by *D* sending = > an INVITE with replaces to *B*. So we'd have to get the Session-ID=20 > value to D so it can use it in its INVITE to B, like by C passing it=20 > in the Refer-To of a REFER to D. OK, so now imagine if B parked the=20 > call and Referred D to C, and you ended up with 2 dialogs A-B, C-D as=20 > below. But they'd be using the same session-id. Is that legit?=20 > (maybe, I dunno) >=20 > A ----------- B C > | > D >=20 > -hadriel >=20 >=20 ------------------------------ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch End of dispatch Digest, Vol 14, Issue 37 **************************************** Peter Dawes=20 From peter.musgrave@magorcorp.com Thu Jun 10 03:15:29 2010 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 62AB83A6954 for ; Thu, 10 Jun 2010 03:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.027 X-Spam-Level: X-Spam-Status: No, score=-0.027 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWtTtchkUIlf for ; Thu, 10 Jun 2010 03:15:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3647E3A6920 for ; Thu, 10 Jun 2010 03:15:28 -0700 (PDT) Received: by vws9 with SMTP id 9so2648756vws.31 for ; Thu, 10 Jun 2010 03:15:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.184.138 with SMTP id ck10mr7921259qcb.130.1276164927181; Thu, 10 Jun 2010 03:15:27 -0700 (PDT) Received: by 10.229.217.16 with HTTP; Thu, 10 Jun 2010 03:15:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 06:15:27 -0400 Message-ID: From: Peter Musgrave To: "Dawes, Peter, VF-Group" Content-Type: text/plain; charset=ISO-8859-1 Cc: dispatch@ietf.org, HKaplan@acmepacket.com Subject: Re: [dispatch] Final Charter for Session-ID? 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, 10 Jun 2010 10:15:29 -0000 Hi, I also agree that this is a genuine problem. I do think that a few user cases would cover a large proportion of the common real world scenarios (auto-attendant, transfer, forward to voice mail etc.) but that to specify this exhaustively will likely prove difficult. Is there any support for the idea that the WG should be chartered to investigate this issue and provide a doc which indicates how B2BUAs should handle the common cases? Either in the session ID draft or [my preference] in a second doc (so that e.g. session-id can be used by sipclf before the the discussion on detailed usage is complete). Peter Musgrave From Peter.Dawes@vodafone.com Thu Jun 10 03:27:48 2010 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 DE2B13A69FA for ; Thu, 10 Jun 2010 03:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, J_CHICKENPOX_84=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 Tyn-CZgA-W15 for ; Thu, 10 Jun 2010 03:27:47 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by core3.amsl.com (Postfix) with ESMTP id 2DA643A69F9 for ; Thu, 10 Jun 2010 03:27:46 -0700 (PDT) Received: from mailint01 (localhost [127.0.0.1]) by mailout01 (Postfix) with ESMTP id 7A50B4ACD for ; Thu, 10 Jun 2010 12:27:46 +0200 (CEST) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint01 (Postfix) with ESMTPS id 6C7134B4C; Thu, 10 Jun 2010 12:27:46 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 12:27:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Jun 2010 12:28:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Final Charter for Session-ID? Thread-Index: AcsIh5u8plT3ueBETLeH1pk17qsExA== From: "Dawes, Peter, VF-Group" To: , X-OriginalArrivalTime: 10 Jun 2010 10:27:47.0664 (UTC) FILETIME=[92336500:01CB0887] Subject: [dispatch] Final Charter for Session-ID? 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, 10 Jun 2010 10:27:49 -0000 Hello Hadriel, All, I believe that the session-ID header field is very useful and should be described in an RFC. However, for troubleshooting across many network entities where the message path is not known beforehand, http://www.ietf.org/id/draft-dawes-sipping-debug-02.txt describes a targetted approach that avoids having to look for session-ID in all messages everywhere in the network. I believe that my draft is a specialization of session-ID and could be written as an extension to it. Does the proposed charter text allow my draft to be added to SIPSCOTCH working group discussions? If not, I would like to propose adding it to the charter. Thanks. Regards, Peter ------------------------------------------------------------------- Howdy, I have heard no objections to this version of the charter (other than a debate about how to solve it). =20 If you have any comments regarding the charter, please speak now. Thanks! -hadriel SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCOTCH) Charter: ---------------------------------- The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of the same higher-level end-to-end "session" across multiple SIP device hops for the same "message-flow", for the purpose of troubleshooting. In particular, the mechanism must be able to allow such correlation across SIP B2BUAs of as many functional types as possible, such as Application Servers, Softswitches, PBXs, SBCs, etc. The definition of a higher-layer "session" of the same "message-flow" is not defined by SIP when it involves a B2BUA, and is difficult to normatively define in practice. For the purposes of this WG charter's scope, two or more dialogs of a B2BUA are correlated under any conditions where correlation might aid troubleshooting, by identifying them as belonging to the same higher-level session. Any solution documents from this working group may expand or constrain the scope of their mechanism's correlation, if the working group so decides. Although other solutions may be possible, this working group will focus on defining a new SIP Header field for such a purpose, similar to the Call-ID header field, in order to provide a simple, easily deployable mechanism which can work across SIP domains. The SIP Call-ID header field value itself is not usable for such correlation, because many B2BUAs must create a new Call-ID value on their UAC "side" in order to function properly, and to comply with the rules of RFC 3261.=20 It should be noted that certain SIP B2BUAs perform a "topology-hiding" function, as described in RFC 5853. The working group will take such functions into account for the correlation mechanism, as well as provide guidance for implementers of the mechanism to avoid triggering such a function for the mechanism's header field value. Lastly, although in certain environments such a mechanism may be usable for dialog correlation in SIP state machines, it is not the goal of this working group to address that usage. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 2010 - New header specification to IESG (PS) Peter Dawes=20 Group R&D =20 Tel: +44 (0)7717 275009 Fax: +44 (0)1635 234873 =20 E-mail: peter.dawes@vodafone.com =20 www.betavine.net - Web betavine.mobi - Mobile Web =20 Vodafone Group Services Limited=20 Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 From pkyzivat@cisco.com Thu Jun 10 05:53:37 2010 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 2B5CA3A6830 for ; Thu, 10 Jun 2010 05:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.201 X-Spam-Level: X-Spam-Status: No, score=-9.201 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKkvVXcSQHXn for ; Thu, 10 Jun 2010 05:53:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3B0483A6811 for ; Thu, 10 Jun 2010 05:53:35 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,398,1272844800"; d="scan'208";a="120024984" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Jun 2010 12:53:36 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5ACraPO010331; Thu, 10 Jun 2010 12:53:36 GMT Message-ID: <4C10E050.5090102@cisco.com> Date: Thu, 10 Jun 2010 08:53:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> <1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] Final Charter for Session-ID? 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, 10 Jun 2010 12:53:37 -0000 Muthu ArulMozhi Perumal (mperumal) wrote: > Here is an initial attempt: > > If there is a dialog between A and B then A and B are in a session. > If there is a dialog between A and B and a dialog between B and C at the > same time then A, B and C are in a session. > More generally, if two or more participants are part of a session S and > at the same time there is a dialog between one of the participants of S > and another participant Z who is not part of S, then S (union) Z is a > session. The above just reiterates the problem that Cullen was raising. Just because B has a dialog with A and a dialog with C does not mean that there is a session between A and C. A gateway provides a perfect example of that. There needs to be some semantic link between the dialogs. The question is defining what sorts of semantic links should be used to share a session id. Thanks, Paul > I think this would cover most of SBC, 3PCC an app server cases. People > can add cases like park/retrieve if they think they should be considered > as part of a single session. > > Muthu > > |-----Original Message----- > |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > |Of Cullen Jennings (fluffy) > |Sent: Wednesday, June 09, 2010 8:23 PM > |To: DISPATCH list > |Subject: Re: [dispatch] Final Charter for Session-ID? > | > |I have a problem with this proposed charter. > | > |On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: > | > |> > |> The definition of a higher-layer "session" of the same "message-flow" > is > |not defined by SIP when it involves a B2BUA, and is difficult to > normatively > |define in practice. For the purposes of this WG charter's scope, two > or > |more dialogs of a B2BUA are correlated under any conditions where > |correlation might aid troubleshooting, by identifying them as belonging > to > |the same higher-level session. Any solution documents from this working > |group may expand or constrain the scope of their mechanism's > correlation, if > |the working group so decides. > | > |I think the above text is way too vague and impossible to reduce to > |engineering practice. If you have 10 calls going to a PSTN GWs that is > |having voice quality problems, clearly having all of them grouped > together > |is useful in debugging. Yet I doubt we want all the calls from a given > PSTN > |GW to have the same correlation ID. Our lack of any solid definition of > what > |it is we are trying to correlate is a strong indication to me that we > have > |not yet come to any consensus about what the problem is this WG would > be > |trying to fix. > | > |I would like to see a WG charted in this area but I would expect the > IESG to > |more or less laugh at a problem statement that reduced down to "uh > might be > |useful for debuggin". Can some people please try and propose a more > concrete > |definition of when two sip dialogs will be correlated? > | > |Cullen > | > |_______________________________________________ > |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 Thu Jun 10 05:57:46 2010 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 B95F13A68A3 for ; Thu, 10 Jun 2010 05:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_20=-0.74, 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 N2c67R1U0fYz for ; Thu, 10 Jun 2010 05:57:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CD0BB3A69FD for ; Thu, 10 Jun 2010 05:57:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-6b-4c10e1492d83 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 30.98.29106.941E01C4; Thu, 10 Jun 2010 14:57:45 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 10 Jun 2010 14:57:45 +0200 From: Christer Holmberg To: Paul Kyzivat , "Muthu ArulMozhi Perumal (mperumal)" Date: Thu, 10 Jun 2010 14:57:44 +0200 Thread-Topic: [dispatch] Final Charter for Session-ID? Thread-Index: AcsIm/7pkUJumabnQpavzioWJPPf7AAAEcng Message-ID: References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> <1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> <4C10E050.5090102@cisco.com> In-Reply-To: <4C10E050.5090102@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] Final Charter for Session-ID? 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, 10 Jun 2010 12:57:46 -0000 Hi, Isn't the linkage the fact that C is the person A addressed for this specif= ic session? Regards, Christer =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 10. kes=E4kuuta 2010 15:54 > To: Muthu ArulMozhi Perumal (mperumal) > Cc: DISPATCH list > Subject: Re: [dispatch] Final Charter for Session-ID? >=20 >=20 >=20 > Muthu ArulMozhi Perumal (mperumal) wrote: > > Here is an initial attempt: > >=20 > > If there is a dialog between A and B then A and B are in a session. > > If there is a dialog between A and B and a dialog between B=20 > and C at=20 > > the same time then A, B and C are in a session. > > More generally, if two or more participants are part of a session S=20 > > and at the same time there is a dialog between one of the=20 > participants=20 > > of S and another participant Z who is not part of S, then S=20 > (union) Z=20 > > is a session. >=20 > The above just reiterates the problem that Cullen was raising. > Just because B has a dialog with A and a dialog with C does=20 > not mean that there is a session between A and C. A gateway=20 > provides a perfect example of that. >=20 > There needs to be some semantic link between the dialogs. The=20 > question is defining what sorts of semantic links should be=20 > used to share a session id. >=20 > Thanks, > Paul >=20 > > I think this would cover most of SBC, 3PCC an app server=20 > cases. People=20 > > can add cases like park/retrieve if they think they should be=20 > > considered as part of a single session. > >=20 > > Muthu > >=20 > > |-----Original Message----- > > |From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > Behalf > > |Of Cullen Jennings (fluffy) > > |Sent: Wednesday, June 09, 2010 8:23 PM > > |To: DISPATCH list > > |Subject: Re: [dispatch] Final Charter for Session-ID? > > | > > |I have a problem with this proposed charter. > > | > > |On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: > > | > > |> > > |> The definition of a higher-layer "session" of the same=20 > "message-flow" > > is > > |not defined by SIP when it involves a B2BUA, and is difficult to > > normatively > > |define in practice. For the purposes of this WG charter's=20 > scope, two > > or > > |more dialogs of a B2BUA are correlated under any conditions where=20 > > |correlation might aid troubleshooting, by identifying them as=20 > > |belonging > > to > > |the same higher-level session. Any solution documents from this=20 > > |working group may expand or constrain the scope of their=20 > mechanism's > > correlation, if > > |the working group so decides. > > | > > |I think the above text is way too vague and impossible to=20 > reduce to=20 > > |engineering practice. If you have 10 calls going to a PSTN=20 > GWs that=20 > > |is having voice quality problems, clearly having all of=20 > them grouped > > together > > |is useful in debugging. Yet I doubt we want all the calls from a=20 > > |given > > PSTN > > |GW to have the same correlation ID. Our lack of any solid=20 > definition=20 > > |of > > what > > |it is we are trying to correlate is a strong indication to=20 > me that we > > have > > |not yet come to any consensus about what the problem is=20 > this WG would > > be > > |trying to fix. > > | > > |I would like to see a WG charted in this area but I would=20 > expect the > > IESG to > > |more or less laugh at a problem statement that reduced down to "uh > > might be > > |useful for debuggin". Can some people please try and propose a more > > concrete > > |definition of when two sip dialogs will be correlated? > > | > > |Cullen > > | > > |_______________________________________________ > > |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 mperumal@cisco.com Thu Jun 10 06:22:51 2010 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 586BA3A692D for ; Thu, 10 Jun 2010 06:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnOCpx1-r1RT for ; Thu, 10 Jun 2010 06:22:50 -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 349933A6968 for ; Thu, 10 Jun 2010 06:22:50 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJuDEExAaHte/2dsb2JhbACeXHGjfZoshRgEg0k X-IronPort-AV: E=Sophos;i="4.53,398,1272844800"; d="scan'208";a="226004521" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-3.cisco.com with ESMTP; 10 Jun 2010 13:22:51 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5ADLnoa005300; Thu, 10 Jun 2010 13:22:50 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Jun 2010 18:52:01 +0530 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, 10 Jun 2010 18:52:00 +0530 Message-ID: <1D062974A4845E4D8A343C653804920202E2BF0B@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Final Charter for Session-ID? Thread-Index: AcsIm/7pkUJumabnQpavzioWJPPf7AAAEcngAACgddA= References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail><1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> <4C10E050.5090102@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Christer Holmberg" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 10 Jun 2010 13:22:01.0451 (UTC) FILETIME=[E924B3B0:01CB089F] Cc: DISPATCH list Subject: Re: [dispatch] Final Charter for Session-ID? 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, 10 Jun 2010 13:22:51 -0000 Yes, the fact that A and C are communicating is the linkage -- B is just = facilitating that communication. thanks, Muthu=20 |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Thursday, June 10, 2010 6:28 PM |To: Paul Kyzivat (pkyzivat); Muthu ArulMozhi Perumal (mperumal) |Cc: DISPATCH list |Subject: RE: [dispatch] Final Charter for Session-ID? | | |Hi, | |Isn't the linkage the fact that C is the person A addressed for this |specific session? | |Regards, | |Christer | |> -----Original Message----- |> From: dispatch-bounces@ietf.org |> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat |> Sent: 10. kes=E4kuuta 2010 15:54 |> To: Muthu ArulMozhi Perumal (mperumal) |> Cc: DISPATCH list |> Subject: Re: [dispatch] Final Charter for Session-ID? |> |> |> |> Muthu ArulMozhi Perumal (mperumal) wrote: |> > Here is an initial attempt: |> > |> > If there is a dialog between A and B then A and B are in a session. |> > If there is a dialog between A and B and a dialog between B |> and C at |> > the same time then A, B and C are in a session. |> > More generally, if two or more participants are part of a session S |> > and at the same time there is a dialog between one of the |> participants |> > of S and another participant Z who is not part of S, then S |> (union) Z |> > is a session. |> |> The above just reiterates the problem that Cullen was raising. |> Just because B has a dialog with A and a dialog with C does |> not mean that there is a session between A and C. A gateway |> provides a perfect example of that. |> |> There needs to be some semantic link between the dialogs. The |> question is defining what sorts of semantic links should be |> used to share a session id. |> |> Thanks, |> Paul |> |> > I think this would cover most of SBC, 3PCC an app server |> cases. People |> > can add cases like park/retrieve if they think they should be |> > considered as part of a single session. |> > |> > Muthu |> > |> > |-----Original Message----- |> > |From: dispatch-bounces@ietf.org |> [mailto:dispatch-bounces@ietf.org] On |> > Behalf |> > |Of Cullen Jennings (fluffy) |> > |Sent: Wednesday, June 09, 2010 8:23 PM |> > |To: DISPATCH list |> > |Subject: Re: [dispatch] Final Charter for Session-ID? |> > | |> > |I have a problem with this proposed charter. |> > | |> > |On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: |> > | |> > |> |> > |> The definition of a higher-layer "session" of the same |> "message-flow" |> > is |> > |not defined by SIP when it involves a B2BUA, and is difficult to |> > normatively |> > |define in practice. For the purposes of this WG charter's |> scope, two |> > or |> > |more dialogs of a B2BUA are correlated under any conditions where |> > |correlation might aid troubleshooting, by identifying them as |> > |belonging |> > to |> > |the same higher-level session. Any solution documents from this |> > |working group may expand or constrain the scope of their |> mechanism's |> > correlation, if |> > |the working group so decides. |> > | |> > |I think the above text is way too vague and impossible to |> reduce to |> > |engineering practice. If you have 10 calls going to a PSTN |> GWs that |> > |is having voice quality problems, clearly having all of |> them grouped |> > together |> > |is useful in debugging. Yet I doubt we want all the calls from a |> > |given |> > PSTN |> > |GW to have the same correlation ID. Our lack of any solid |> definition |> > |of |> > what |> > |it is we are trying to correlate is a strong indication to |> me that we |> > have |> > |not yet come to any consensus about what the problem is |> this WG would |> > be |> > |trying to fix. |> > | |> > |I would like to see a WG charted in this area but I would |> expect the |> > IESG to |> > |more or less laugh at a problem statement that reduced down to "uh |> > might be |> > |useful for debuggin". Can some people please try and propose a = more |> > concrete |> > |definition of when two sip dialogs will be correlated? |> > | |> > |Cullen |> > | |> > |_______________________________________________ |> > |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 pkyzivat@cisco.com Thu Jun 10 07:14:44 2010 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 DAC4528C114 for ; Thu, 10 Jun 2010 07:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3pZl9W318Se for ; Thu, 10 Jun 2010 07:14:40 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E5EC828C0E7 for ; Thu, 10 Jun 2010 07:14:39 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,398,1272844800"; d="scan'208";a="120057759" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Jun 2010 14:14:41 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5AEEfiS019458; Thu, 10 Jun 2010 14:14:41 GMT Message-ID: <4C10F352.6020905@cisco.com> Date: Thu, 10 Jun 2010 10:14:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail><1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> <4C10E050.5090102@cisco.com> <1D062974A4845E4D8A343C653804920202E2BF0B@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920202E2BF0B@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: DISPATCH list Subject: Re: [dispatch] Final Charter for Session-ID? 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, 10 Jun 2010 14:14:44 -0000 Muthu ArulMozhi Perumal (mperumal) wrote: > Yes, the fact that A and C are communicating is the linkage -- B is just facilitating that communication. Then that needs to be specified. Thanks, Paul > thanks, > Muthu > > |-----Original Message----- > |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > |Sent: Thursday, June 10, 2010 6:28 PM > |To: Paul Kyzivat (pkyzivat); Muthu ArulMozhi Perumal (mperumal) > |Cc: DISPATCH list > |Subject: RE: [dispatch] Final Charter for Session-ID? > | > | > |Hi, > | > |Isn't the linkage the fact that C is the person A addressed for this > |specific session? > | > |Regards, > | > |Christer > | > |> -----Original Message----- > |> From: dispatch-bounces@ietf.org > |> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > |> Sent: 10. kesäkuuta 2010 15:54 > |> To: Muthu ArulMozhi Perumal (mperumal) > |> Cc: DISPATCH list > |> Subject: Re: [dispatch] Final Charter for Session-ID? > |> > |> > |> > |> Muthu ArulMozhi Perumal (mperumal) wrote: > |> > Here is an initial attempt: > |> > > |> > If there is a dialog between A and B then A and B are in a session. > |> > If there is a dialog between A and B and a dialog between B > |> and C at > |> > the same time then A, B and C are in a session. > |> > More generally, if two or more participants are part of a session S > |> > and at the same time there is a dialog between one of the > |> participants > |> > of S and another participant Z who is not part of S, then S > |> (union) Z > |> > is a session. > |> > |> The above just reiterates the problem that Cullen was raising. > |> Just because B has a dialog with A and a dialog with C does > |> not mean that there is a session between A and C. A gateway > |> provides a perfect example of that. > |> > |> There needs to be some semantic link between the dialogs. The > |> question is defining what sorts of semantic links should be > |> used to share a session id. > |> > |> Thanks, > |> Paul > |> > |> > I think this would cover most of SBC, 3PCC an app server > |> cases. People > |> > can add cases like park/retrieve if they think they should be > |> > considered as part of a single session. > |> > > |> > Muthu > |> > > |> > |-----Original Message----- > |> > |From: dispatch-bounces@ietf.org > |> [mailto:dispatch-bounces@ietf.org] On > |> > Behalf > |> > |Of Cullen Jennings (fluffy) > |> > |Sent: Wednesday, June 09, 2010 8:23 PM > |> > |To: DISPATCH list > |> > |Subject: Re: [dispatch] Final Charter for Session-ID? > |> > | > |> > |I have a problem with this proposed charter. > |> > | > |> > |On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: > |> > | > |> > |> > |> > |> The definition of a higher-layer "session" of the same > |> "message-flow" > |> > is > |> > |not defined by SIP when it involves a B2BUA, and is difficult to > |> > normatively > |> > |define in practice. For the purposes of this WG charter's > |> scope, two > |> > or > |> > |more dialogs of a B2BUA are correlated under any conditions where > |> > |correlation might aid troubleshooting, by identifying them as > |> > |belonging > |> > to > |> > |the same higher-level session. Any solution documents from this > |> > |working group may expand or constrain the scope of their > |> mechanism's > |> > correlation, if > |> > |the working group so decides. > |> > | > |> > |I think the above text is way too vague and impossible to > |> reduce to > |> > |engineering practice. If you have 10 calls going to a PSTN > |> GWs that > |> > |is having voice quality problems, clearly having all of > |> them grouped > |> > together > |> > |is useful in debugging. Yet I doubt we want all the calls from a > |> > |given > |> > PSTN > |> > |GW to have the same correlation ID. Our lack of any solid > |> definition > |> > |of > |> > what > |> > |it is we are trying to correlate is a strong indication to > |> me that we > |> > have > |> > |not yet come to any consensus about what the problem is > |> this WG would > |> > be > |> > |trying to fix. > |> > | > |> > |I would like to see a WG charted in this area but I would > |> expect the > |> > IESG to > |> > |more or less laugh at a problem statement that reduced down to "uh > |> > might be > |> > |useful for debuggin". Can some people please try and propose a more > |> > concrete > |> > |definition of when two sip dialogs will be correlated? > |> > | > |> > |Cullen > |> > | > |> > |_______________________________________________ > |> > |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 christer.holmberg@ericsson.com Fri Jun 11 04:03:19 2010 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 6DEB33A695B for ; Fri, 11 Jun 2010 04:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=-1.287, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYiGyC+ahtQq for ; Fri, 11 Jun 2010 04:03:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 494F53A6959 for ; Fri, 11 Jun 2010 04:03:18 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-6c-4c1217f647e0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 33.6B.06817.6F7121C4; Fri, 11 Jun 2010 13:03:19 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 11 Jun 2010 13:03:16 +0200 From: Christer Holmberg To: DISPATCH list Date: Fri, 11 Jun 2010 13:03:15 +0200 Thread-Topic: RFC 3680 extensibility Thread-Index: AcsJVbEf5CP1frgBQTGyiKiXjhpJ0w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC7465C6398042ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] RFC 3680 extensibility 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, 11 Jun 2010 11:03:19 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC7465C6398042ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 5.1 of RFC 3680 (reg event package) says: "Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored." However, there is no policy regarding whether the definition of these "othe= r namespaces" needs to be done in IETF - only that they must be ignored if = not supported. 3GPP has been discussing a couple of IMS specific cases, in which such exte= nsion elements/attributes could be used as solution (no decissions have bee= n made yet), so the question is whether it would require IETF work. Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC7465C6398042ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Section 5.1 of RFC 3680 (reg event package) says:
 
"Other elements from different namespaces MAY be= present for the
purposes of extensibility; elements or attributes fro= m unknown
namespaces MUST be ignored."
 
However, there is no policy regarding whether the def= inition of these "other namespaces" needs to be done in IETF - on= ly that they must be ignored if not supported.
 
3GPP has been discussing a couple of IMS specific cas= es, in which such extension elements/attributes could be used as solution (= no decissions have been made yet), so the question is whether it would requ= ire IETF work.
 
Regards,
 
Christer
 
 
 
 
 
 
 
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC7465C6398042ESESSCMS0354e_-- From gonzalo.camarillo@ericsson.com Fri Jun 11 04:59:02 2010 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 776B728C0E5 for ; Fri, 11 Jun 2010 04:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.781 X-Spam-Level: X-Spam-Status: No, score=-103.781 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_50=0.001, 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 54YvmSFmNSB3 for ; Fri, 11 Jun 2010 04:59:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D3BFC3A67EB for ; Fri, 11 Jun 2010 04:58:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-ae-4c1225009eb9 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.A7.29106.005221C4; Fri, 11 Jun 2010 13:58:56 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jun 2010 13:58:56 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Jun 2010 13:58:56 +0200 Message-ID: <4C1224FF.5050105@ericsson.com> Date: Fri, 11 Jun 2010 14:58:55 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2010 11:58:56.0231 (UTC) FILETIME=[78223F70:01CB095D] X-Brightmail-Tracker: AAAAAA== Cc: Robert Sparks , DISPATCH Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs 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, 11 Jun 2010 11:59:02 -0000 Hi, yes, Mary's description is correct. The process is as follows. Once we agreed on the charter, I requested the IESG to review it. This charter will be discussed in the next IESG telechat (the coming Thursday), actually. Once the IESG is happy with it, the next step will be to have an IETF-wide review. After that, we will be able to charter the WG. In any case, as we have said a number of times, proponents of a particular piece of work should not stop working on it while we charter their WG. They are encouraged to continue making progress in parallel with the chartering process. Cheers, Gonzalo On 09/06/2010 8:13 PM, Mary Barnes wrote: > Hi Laura, > > We did not consider this topic for pre-IETF-78 focus for the DISPATCH > WG because the ADs are already in the process of preparing the charter > for approval by the IESG, as I understood Gonzalo's emails on the > topic. I'll let ADs discuss the timeline for the chartering and > really it would be up to them as to whether a meeting agenda slot > would be requested for the topic. > > The current model we've been using is that past topics that have been > agreed to be chartered have already been "dispatched" per se, per the > summaries in the wiki: > http://trac.tools.ietf.org/wg/dispatch/trac/wiki > > Thanks, > Mary. > > > > > On Wed, Jun 9, 2010 at 2:19 AM, Laura Liess > wrote: >> Hi Mary, Gonzalo, >> >> What about the Alert-Info URN? We had a lot of discussion about the >> charter and name, my opinion was that we had consensus on the charter. >> Dale would chair the WG. I intend to submit a new draft version by >> the end of June. >> I also sent to you an e-mail some time ago asking for a time slot for >> discussion in Masstricht. Is it anything I missed to do to get agenda >> time? >> >> Thanks a lot >> Laura >> >> >> >> >> 2010/6/8 Mary Barnes : >>> Hi all, >>> >>> Per the reminder posted on the ML on May 4th and as listed on the >>> DISPATCH WG wiki, charter proposals for the topics to be >>> handled/dispatched prior to and at IETF-78 were due on May 31st. >>> >>> We received charter proposals (problem statements/deliverables) for the >>> following, with links to most recent charter proposals and discussion threads. >>> >>> o Session-ID: updated charter proposal available >>> http://www.ietf.org/mail-archive/web/dispatch/current/msg01967.html >>> >>> o Telepresence: updated charter proposal available >>> http://www.ietf.org/mail-archive/web/dispatch/current/msg01936.html >>> >>> o VIPR: charter proposal >>> http://www.ietf.org/mail-archive/web/dispatch/current/msg01930.html >>> >>> o TEL URI WG proposal: discussion to focus on problem statement and scope >>> http://www.ietf.org/mail-archive/web/dispatch/current/msg01920.html >>> >>> The above items are the current targets for IETF-78 discussions. Based >>> on those discussions, agenda time will be allocated, items dispatched >>> and adhocs scheduled as appropriate. Note, that the minimum time we >>> would allocate to a topic is 30 minutes and some may warrant 45 >>> minutes. If we schedule adhocs, we will try to have those announced >>> around the time the agenda is finalized. >>> >>> The following items have also been discussed on the mailing list, but >>> are not yet ready for dispatching: >>> >>> o NGN Reason: Some interest. Needs more discussion and scoping. >>> http://datatracker.ietf.org/doc/draft-jesske-dispatch-reason-in-responses/ >>> http://datatracker.ietf.org/doc/draft-jesske-dispatch-req-reason-in-responses/ >>> >>> o PAN - wait for more energy >>> http://datatracker.ietf.org/doc/draft-lawrence-sipforum-provider-alias/ >>> >>> o ACH - ACH analysis draft to happen as part of BLISS wind down >>> http://datatracker.ietf.org/doc/draft-ietf-bliss-ach-analysis/ >>> >>> o ACH - HTTP API docs - need some hallway discussions >>> http://datatracker.ietf.org/doc/draft-yusef-dispatch-ach-rest-api/ >>> >>> o Media security - needs additional ML discussion >>> http://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-parameter/ >>> >>> o Communication diversion and barring notification - feedback thus far >>> needs to be considered - i.e, problem statement to be clarified and >>> alternate solutions to be consider (Note: IPR on the communication >>> diversion draft) >>> http://datatracker.ietf.org/doc/draft-avasarala-dispatch-comm-div-notification/ >>> http://datatracker.ietf.org/doc/-avasarala-dispatch-comm-barring-notification/ >>> >>> >>> As a reminder, the following are the cutoffs for drafts, so please make >>> sure that any drafts relevant to the topic are submitted prior to those >>> deadlines: >>> * - 00 documents: July 5th (< 4 weeks) >>> * all other documents: July 12th (< 5 weeks) >>> >>> Please keep in mind that the focus of discussions should be the problem >>> statement, scope and proposed deliverables for the topic. >>> >>> As a reminder, items can be dispatched without being discussed at a f2f >>> meeting and the most effective way to achieve this is to have problem >>> statements, scope of topics and any relevant documents available for >>> discussion, rather than documents focusing on solutions. >>> >>> Please, let the chairs know if there are any concerns. >>> >>> Thanks, >>> Mary Barnes and Cullen Jennings >>> DISPATCH WG chairs >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> From dworley@avaya.com Fri Jun 11 09:09:11 2010 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 95AEA28C0E8 for ; Fri, 11 Jun 2010 09:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r1DrwvGD+B9 for ; Fri, 11 Jun 2010 09:09:10 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 7ABB728C0E1 for ; Fri, 11 Jun 2010 09:09:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,404,1272859200"; d="scan'208";a="20180904" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 11 Jun 2010 12:09:03 -0400 X-IronPort-AV: E=Sophos;i="4.53,404,1272859200"; d="scan'208";a="471673527" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Jun 2010 12:08:33 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 11 Jun 2010 12:08:33 -0400 From: "WORLEY, Dale R (Dale)" To: Christer Holmberg , DISPATCH list Date: Fri, 11 Jun 2010 12:06:29 -0400 Thread-Topic: RFC 3680 extensibility Thread-Index: AcsJVbEf5CP1frgBQTGyiKiXjhpJ0wAKlxzh 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 Subject: Re: [dispatch] RFC 3680 extensibility 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, 11 Jun 2010 16:09:11 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Ch= rister Holmberg [christer.holmberg@ericsson.com] Section 5.1 of RFC 3680 (reg event package) says: "Other elements from different namespaces MAY be present for the purposes of extensibility; elements or attributes from unknown namespaces MUST be ignored." However, there is no policy regarding whether the definition of these "othe= r namespaces" needs to be done in IETF - only that they must be ignored if = not supported. 3GPP has been discussing a couple of IMS specific cases, in which such exte= nsion elements/attributes could be used as solution (no decissions have bee= n made yet), so the question is whether it would require IETF work. ________________________________________ The rule that unknown elements/attributes must be ignored covers you there,= doesn't it? If a non-3GPP system subscribes to an "extended" event packag= e, it will ignore the extensions. Dale From dworley@avaya.com Sun Jun 13 19:40:25 2010 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 0870D3A6804 for ; Sun, 13 Jun 2010 19:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2WbL-wc7KdS for ; Sun, 13 Jun 2010 19:40:24 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id EC2083A67E3 for ; Sun, 13 Jun 2010 19:40:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,412,1272859200"; d="scan'208";a="222852004" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Jun 2010 22:40:27 -0400 X-IronPort-AV: E=Sophos;i="4.53,412,1272859200"; d="scan'208";a="483117201" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Jun 2010 22:40:26 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([::1]) with mapi; Sun, 13 Jun 2010 22:40:26 -0400 From: "WORLEY, Dale R (Dale)" To: Gonzalo Camarillo , Mary Barnes Date: Sun, 13 Jun 2010 22:37:12 -0400 Thread-Topic: [dispatch] DISPATCH-78 topics - Alert URNs Thread-Index: AcsJXXs00HycXaI2R6yBkx/Ino0pAwCDQMbw Message-ID: References: , <4C1224FF.5050105@ericsson.com> In-Reply-To: <4C1224FF.5050105@ericsson.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: Robert Sparks , DISPATCH Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs 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, 14 Jun 2010 02:40:25 -0000 ________________________________________ From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] yes, Mary's description is correct. The process is as follows. Once we agreed on the charter, I requested the IESG to review it. This charter will be discussed in the next IESG telechat (the coming Thursday), actually. Once the IESG is happy with it, the next step will be to have an IETF-wide review. After that, we will be able to charter the WG. In any case, as we have said a number of times, proponents of a particular piece of work should not stop working on it while we charter their WG. They are encouraged to continue making progress in parallel with the chartering process. ________________________________________ That is all fine, but what are the implications regarding getting a time sl= ot at Maastricht? There seem to be two choices: a slot within Dispatch, o= r a separately scheduled Salud session. What we do not want to get stuck w= ith is not being able to get time in Dispatch (because a charter has been p= roposed) and not being able to get a separate session (because the charter = hasn't gone through all the approval steps), as that would prevent any sess= ion at Maastricht. Dale From gonzalo.camarillo@ericsson.com Sun Jun 13 22:55:58 2010 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 012A528B797 for ; Sun, 13 Jun 2010 22:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.125 X-Spam-Level: X-Spam-Status: No, score=-103.125 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLDjW9bo+Z3p for ; Sun, 13 Jun 2010 22:55:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id CD2BF3A684A for ; Sun, 13 Jun 2010 22:55:56 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-be-4c15c46e9642 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E0.99.06817.E64C51C4; Mon, 14 Jun 2010 07:55:58 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jun 2010 07:55:58 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jun 2010 07:55:58 +0200 Message-ID: <4C15C46D.3010504@ericsson.com> Date: Mon, 14 Jun 2010 08:55:57 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "WORLEY, Dale R (Dale)" References: , <4C1224FF.5050105@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2010 05:55:58.0137 (UTC) FILETIME=[429E1290:01CB0B86] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH , Robert Sparks Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs 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, 14 Jun 2010 05:55:58 -0000 Hi, if you need face-to-face time for this, go ahead talk to the DISPATCH chairs so that you can either get a slot within the DISPATCH session or, alternatively, have an ad-hoc meeting. If we managed to charter the WG in time, we would have a WG meeting instead. Cheers, Gonzalo On 14/06/2010 5:37 AM, WORLEY, Dale R (Dale) wrote: > ________________________________________ > From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] > > yes, Mary's description is correct. The process is as follows. Once we > agreed on the charter, I requested the IESG to review it. This charter > will be discussed in the next IESG telechat (the coming Thursday), > actually. Once the IESG is happy with it, the next step will be to have > an IETF-wide review. After that, we will be able to charter the WG. > > In any case, as we have said a number of times, proponents of a > particular piece of work should not stop working on it while we charter > their WG. They are encouraged to continue making progress in parallel > with the chartering process. > ________________________________________ > > That is all fine, but what are the implications regarding getting a time slot at Maastricht? There seem to be two choices: a slot within Dispatch, or a separately scheduled Salud session. What we do not want to get stuck with is not being able to get time in Dispatch (because a charter has been proposed) and not being able to get a separate session (because the charter hasn't gone through all the approval steps), as that would prevent any session at Maastricht. > > Dale From laura.liess.dt@googlemail.com Sun Jun 13 23:14:18 2010 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 868483A687D for ; Sun, 13 Jun 2010 23:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.489 X-Spam-Level: X-Spam-Status: No, score=-0.489 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY-XlVUb9m2g for ; Sun, 13 Jun 2010 23:14:17 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5A2173A6878 for ; Sun, 13 Jun 2010 23:14:17 -0700 (PDT) Received: by wyi11 with SMTP id 11so2679159wyi.31 for ; Sun, 13 Jun 2010 23:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=byRVG8XJfBUm1cdq2BJAvbtn48R0Lgw3j+77iNfLyEs=; b=I1Dr6AaLV2OEwoyC2x399UGXwhpKv7oggO4oYUb6rAc2CYjfs6BkH5i9YuogBXoPCY 1m3cJUrWmKQSc9CSJrUr2lN61Tz9rX7fYrIpiJBrtDW6Jg5zjITLVpLi3iEExzrS6lEQ vKepttFye5sVWLPcxeAWETp3fS9EGBhB9HLbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=D3KaaR216US31g+u79b+zxYK+0XrAdfxaYyJ5kYICcS1DgmwZTabkGDPbSI66lQ1/v xpWoj9SXGkfy2UYFgsXrt9S8w7v0IvuW3Mmq0fnmiNUwugr8/UOUWul69Fs++7VdVu2U mRPyT/XflzWr8SDxdm2lcdGyP+T9e54g9zQ2o= MIME-Version: 1.0 Received: by 10.216.88.72 with SMTP id z50mr1942269wee.60.1276496055878; Sun, 13 Jun 2010 23:14:15 -0700 (PDT) Received: by 10.216.169.9 with HTTP; Sun, 13 Jun 2010 23:14:15 -0700 (PDT) In-Reply-To: <4C15C46D.3010504@ericsson.com> References: <4C1224FF.5050105@ericsson.com> <4C15C46D.3010504@ericsson.com> Date: Mon, 14 Jun 2010 08:14:15 +0200 Message-ID: From: Laura Liess To: Gonzalo Camarillo , "WORLEY, Dale R (Dale)" , Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Sparks , DISPATCH Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs 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, 14 Jun 2010 06:14:18 -0000 Hi, Dale is right. We need a face2face meeting again. Thanks, Laura 2010/6/14 Gonzalo Camarillo : > Hi, > > if you need face-to-face time for this, go ahead talk to the DISPATCH > chairs so that you can either get a slot within the DISPATCH session or, > alternatively, have an ad-hoc meeting. If we managed to charter the WG > in time, we would have a WG meeting instead. > > Cheers, > > Gonzalo > > On 14/06/2010 5:37 AM, WORLEY, Dale R (Dale) wrote: >> ________________________________________ >> From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] >> >> yes, Mary's description is correct. The process is as follows. Once we >> agreed on the charter, I requested the IESG to review it. This charter >> will be discussed in the next IESG telechat (the coming Thursday), >> actually. Once the IESG is happy with it, the next step will be to have >> an IETF-wide review. After that, we will be able to charter the WG. >> >> In any case, as we have said a number of times, proponents of a >> particular piece of work should not stop working on it while we charter >> their WG. They are encouraged to continue making progress in parallel >> with the chartering process. >> ________________________________________ >> >> That is all fine, but what are the implications regarding getting a time= slot at Maastricht? =A0There seem to be two choices: =A0a slot within Disp= atch, or a separately scheduled Salud session. =A0What we do not want to ge= t stuck with is not being able to get time in Dispatch (because a charter h= as been proposed) and not being able to get a separate session (because the= charter hasn't gone through all the approval steps), as that would prevent= any session at =A0Maastricht. >> >> Dale > > From gonzalo.camarillo@ericsson.com Sun Jun 13 23:42:20 2010 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 B93133A680C for ; Sun, 13 Jun 2010 23:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.171 X-Spam-Level: X-Spam-Status: No, score=-104.171 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_20=-0.74, 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 Fi7RfjrlKIj0 for ; Sun, 13 Jun 2010 23:42:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6A8C73A676A for ; Sun, 13 Jun 2010 23:42:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-5b-4c15cf4dcd4c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BC.45.29106.D4FC51C4; Mon, 14 Jun 2010 08:42:21 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jun 2010 08:42:20 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jun 2010 08:42:20 +0200 Message-ID: <4C15CF4C.8060506@ericsson.com> Date: Mon, 14 Jun 2010 09:42:20 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "WORLEY, Dale R (Dale)" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2010 06:42:20.0875 (UTC) FILETIME=[BD4231B0:01CB0B8C] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] RFC 3680 extensibility 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, 14 Jun 2010 06:42:20 -0000 Hi, yes, I agree with Dale that, technically, the system is ready to handle interoperability even in presence of unknown stuff... but the question here is whether or not we have a policy that regulates the creation of such extensions. XML namespaces are not covered by RFC 5727. However, Section 4.2 of RFC 3863 specifies rules for registering extensions to the basic presence information data format: http://tools.ietf.org/html/rfc3863#section-4.2 Considering the spirit of RFC 5727 and the example above, a potential policy could be to register reg-event extensions with the IANA using the Specification Required policy defined in RFC 5226. In this case, this would mean that the extension would be defined in a 3GPP spec and revised by an expert who would be designated by the RAI ADs. The expert reviewer would make sure that new extensions do not overlap with current IETF work. In any case, we would welcome further comments on this issue. Thanks, Gonzalo On 11/06/2010 7:06 PM, WORLEY, Dale R (Dale) wrote: > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg [christer.holmberg@ericsson.com] > > Section 5.1 of RFC 3680 (reg event package) says: > > "Other elements from different namespaces MAY be present for the > purposes of extensibility; elements or attributes from unknown > namespaces MUST be ignored." > > However, there is no policy regarding whether the definition of these "other namespaces" needs to be done in IETF - only that they must be ignored if not supported. > > 3GPP has been discussing a couple of IMS specific cases, in which such extension elements/attributes could be used as solution (no decissions have been made yet), so the question is whether it would require IETF work. > ________________________________________ > > The rule that unknown elements/attributes must be ignored covers you there, doesn't it? If a non-3GPP system subscribes to an "extended" event package, it will ignore the extensions. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From aallen@rim.com Mon Jun 14 00:03:46 2010 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 CDF0D3A684C for ; Mon, 14 Jun 2010 00:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.714 X-Spam-Level: X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 AkfoU-8fyO0K for ; Mon, 14 Jun 2010 00:03:45 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 739053A683C for ; Mon, 14 Jun 2010 00:03:44 -0700 (PDT) X-AuditID: 0a666446-b7be7ae000007093-f3-4c15d453abe6 Received: from XCH138CNC.rim.net ( [10.65.20.127]) by mhs04ykf.rim.net (RIM Mail) with SMTP id AF.DE.28819.354D51C4; Mon, 14 Jun 2010 03:03:47 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH138CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jun 2010 03:03:46 -0400 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: Mon, 14 Jun 2010 02:03:44 -0500 Message-ID: In-Reply-To: <4C15CF4C.8060506@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] RFC 3680 extensibility Thread-Index: AcsLjMOXqSOIMmAPR1iikRa+4MtZoAAAvYgj From: "Andrew Allen" To: , X-OriginalArrivalTime: 14 Jun 2010 07:03:46.0680 (UTC) FILETIME=[BBA87780:01CB0B8F] X-Brightmail-Tracker: AAAAAQAAAZE= Cc: dispatch@ietf.org Subject: Re: [dispatch] RFC 3680 extensibility 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, 14 Jun 2010 07:03:46 -0000 Gonzalo I would pretty much agree with this approach. Only thing I would add is that= the expert reviewer should also verify that there is no implied Require opt= ion-tag i.e. that subscribers supporting the extension still can perform bas= ic functionality with notifiers that do not support the extension otherwise= I think we require new option-tags and that means standards track. Andrew ----- Original Message ----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] Sent: Monday, June 14, 2010 02:42 AM To: WORLEY, Dale R (Dale) Cc: DISPATCH list Subject: Re: [dispatch] RFC 3680 extensibility Hi, yes, I agree with Dale that, technically, the system is ready to handle interoperability even in presence of unknown stuff... but the question here is whether or not we have a policy that regulates the creation of such extensions. XML namespaces are not covered by RFC 5727. However, Section 4.2 of RFC 3863 specifies rules for registering extensions to the basic presence information data format: http://tools.ietf.org/html/rfc3863#section-4.2 Considering the spirit of RFC 5727 and the example above, a potential policy could be to register reg-event extensions with the IANA using the Specification Required policy defined in RFC 5226. In this case, this would mean that the extension would be defined in a 3GPP spec and revised by an expert who would be designated by the RAI ADs. The expert reviewer would make sure that new extensions do not overlap with current IETF work. In any case, we would welcome further comments on this issue. Thanks, Gonzalo On 11/06/2010 7:06 PM, WORLEY, Dale R (Dale) wrote: > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of C= hrister Holmberg [christer.holmberg@ericsson.com] > > Section 5.1 of RFC 3680 (reg event package) says: > > "Other elements from different namespaces MAY be present for the > purposes of extensibility; elements or attributes from unknown > namespaces MUST be ignored." > > However, there is no policy regarding whether the definition of these "oth= er namespaces" needs to be done in IETF - only that they must be ignored if= not supported. > > 3GPP has been discussing a couple of IMS specific cases, in which such ext= ension elements/attributes could be used as solution (no decissions have bee= n made yet), so the question is whether it would require IETF work. > ________________________________________ > > The rule that unknown elements/attributes must be ignored covers you there= , doesn't it? If a non-3GPP system subscribes to an "extended" event packag= e, it will ignore the extensions. > > Dale > _______________________________________________ > 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 --------------------------------------------------------------------- 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. From christer.holmberg@ericsson.com Mon Jun 14 02:17:54 2010 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 7A54A3A684E for ; Mon, 14 Jun 2010 02:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 Qncbuak1d8pP for ; Mon, 14 Jun 2010 02:17:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4EED63A688E for ; Mon, 14 Jun 2010 02:17:52 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-10-4c15f3c346e4 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DC.87.06817.3C3F51C4; Mon, 14 Jun 2010 11:17:55 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 14 Jun 2010 11:17:42 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 14 Jun 2010 11:17:29 +0200 From: Christer Holmberg To: Gonzalo Camarillo , "WORLEY, Dale R (Dale)" Date: Mon, 14 Jun 2010 11:17:28 +0200 Thread-Topic: [dispatch] RFC 3680 extensibility Thread-Index: AcsLjLzuaWegSaUoQum0BgCgTNvXKAAFZ0IQ Message-ID: References: <4C15CF4C.8060506@ericsson.com> In-Reply-To: <4C15CF4C.8060506@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] RFC 3680 extensibility 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, 14 Jun 2010 09:17:54 -0000 Hi, So, it would be the same policy as we have for info packages. Thanks! Regards, Christer =20 > -----Original Message----- > From: Gonzalo Camarillo=20 > Sent: 14. kes=E4kuuta 2010 9:42 > To: WORLEY, Dale R (Dale) > Cc: Christer Holmberg; DISPATCH list > Subject: Re: [dispatch] RFC 3680 extensibility >=20 > Hi, >=20 > yes, I agree with Dale that, technically, the system is ready=20 > to handle interoperability even in presence of unknown=20 > stuff... but the question here is whether or not we have a=20 > policy that regulates the creation of such extensions. >=20 > XML namespaces are not covered by RFC 5727. However, Section=20 > 4.2 of RFC > 3863 specifies rules for registering extensions to the basic=20 > presence information data format: >=20 > http://tools.ietf.org/html/rfc3863#section-4.2 >=20 > Considering the spirit of RFC 5727 and the example above, a=20 > potential policy could be to register reg-event extensions=20 > with the IANA using the Specification Required policy defined=20 > in RFC 5226. In this case, this would mean that the extension=20 > would be defined in a 3GPP spec and revised by an expert who=20 > would be designated by the RAI ADs. The expert reviewer would=20 > make sure that new extensions do not overlap with current IETF work. >=20 > In any case, we would welcome further comments on this issue. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 11/06/2010 7:06 PM, WORLEY, Dale R (Dale) wrote: > > ________________________________________ > > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org]=20 > On Behalf=20 > > Of Christer Holmberg [christer.holmberg@ericsson.com] > >=20 > > Section 5.1 of RFC 3680 (reg event package) says: > >=20 > > "Other elements from different namespaces MAY be present for the=20 > > purposes of extensibility; elements or attributes from unknown=20 > > namespaces MUST be ignored." > >=20 > > However, there is no policy regarding whether the=20 > definition of these "other namespaces" needs to be done in=20 > IETF - only that they must be ignored if not supported. > >=20 > > 3GPP has been discussing a couple of IMS specific cases, in=20 > which such extension elements/attributes could be used as=20 > solution (no decissions have been made yet), so the question=20 > is whether it would require IETF work. > > ________________________________________ > >=20 > > The rule that unknown elements/attributes must be ignored=20 > covers you there, doesn't it? If a non-3GPP system=20 > subscribes to an "extended" event package, it will ignore the=20 > extensions. > >=20 > > Dale > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 > = From dworley@avaya.com Mon Jun 14 18:26:33 2010 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 7ADAF3A6A18 for ; Mon, 14 Jun 2010 18:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.115, 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 884IrzPIEDxI for ; Mon, 14 Jun 2010 18:26:32 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 6D3353A6A17 for ; Mon, 14 Jun 2010 18:26:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,417,1272859200"; d="scan'208";a="20605753" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 14 Jun 2010 21:26:35 -0400 X-IronPort-AV: E=Sophos;i="4.53,417,1272859200"; d="scan'208";a="472426821" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jun 2010 21:26:05 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 14 Jun 2010 21:26:05 -0400 From: "WORLEY, Dale R (Dale)" To: Mary Barnes , Cullen Jennings Date: Mon, 14 Jun 2010 21:26:05 -0400 Thread-Topic: Request for agenda time at IETF-78 Thread-Index: AQHLDCkutnGAefRkOU+gm91TQCoszA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , Gonzalo Camarillo , "L.Liess@telekom.de" Subject: [dispatch] Request for agenda time at IETF-78 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, 15 Jun 2010 01:26:33 -0000 Talking with Laura Liess, it looks like the "Alert-Info URN" effort will ne= ed a time slot of 30 to 45 minutes at Maastricht. (We have only one draft = in progress.) There is ambiguity regarding where in the schedule this shou= ld be put, as the working group is just being approved. However, given the= relatively small amount of time needed, it seems best to me if it could be= put at the end of a Dispatch session or one of the other SIP sessions. I = am told that we already have a time request submitted, but we have heard no= response regarding it. What is likely to work best for the Maastricht meeting? Dale From Peter.Dawes@vodafone.com Tue Jun 15 04:37:44 2010 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 1886328C12B for ; Tue, 15 Jun 2010 04:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.455 X-Spam-Level: X-Spam-Status: No, score=-4.455 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_05=-1.11, 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 JzTo50DzHz5y for ; Tue, 15 Jun 2010 04:37:43 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by core3.amsl.com (Postfix) with ESMTP id A45ED28C127 for ; Tue, 15 Jun 2010 04:37:42 -0700 (PDT) Received: from mailint01 (localhost [127.0.0.1]) by mailout01 (Postfix) with ESMTP id 080594B43 for ; Tue, 15 Jun 2010 13:37:45 +0200 (CEST) Received: from avoexs02.internal.vodafone.com (unknown [145.230.4.135]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint01 (Postfix) with ESMTPS id F1CA749FC for ; Tue, 15 Jun 2010 13:37:44 +0200 (CEST) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Jun 2010 13:37:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Jun 2010 13:38:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: New I-D: draft-dawes-dispatch-mediasec-parameter-01 Thread-Index: AcsMe4Yu6lLZ5L72S+2iiD3imnS7awAA5vhg From: "Dawes, Peter, VF-Group" To: X-OriginalArrivalTime: 15 Jun 2010 11:37:46.0183 (UTC) FILETIME=[2CC74D70:01CB0C7F] Subject: [dispatch] FW: Re: New I-D: draft-dawes-dispatch-mediasec-parameter-01 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, 15 Jun 2010 11:37:44 -0000 Hi, I have submitted a revised draft on media plane security on the first hop to include more background on motivation, add SDP to the examples, and indicate that the entity on the edge of the network is a B2BUA not a proxy.=20 https://datatracker.ietf.org/doc/draft-dawes-dispatch-mediasec-parameter / I have copied the revised motivations clause below.=20 Regards, Peter 1.1. Motivations 1.1.1. Access Network Protection Some access technologies protect the data passed over them by default, for example many cellular wireless accesses, but some do not, for example WLAN. For accesses with no protection, it is useful for the media controlled by SIP signalling to be protected by default because of vulnerability to eavesdropping. It is currently possible for a UA to request protection of the media plane end-to-end by including the crypto attribute in SDP at session setup. This does not guarantee protection however, because it relies on support of encryption by the called UA, or by another entity in the path taken by the media. In some cases, the session will originate in an access that protects the media and terminate in one that does not, meaning that media is protected in all but some hops of its path. In cases where the same provider supplies the user equipment and provides the IP access, the IP access technology that the UA will use is predictable and the media is vulnerable only as far as the core network. In such cases, the user equipment it is possible to protect the media plane by encrypting at the UA and decrypting at the edge of the core network, and for the user agent that originates or terminates the session to expect the edge of the core network to be capable of encrypting and decrypting media. This document describes this case of first-hop protection, which is typically provided by default to a user agent. Both media and signalling must pass through the entity at the edge of the core network, which must therefore be a back-to-back user agent (B2BUA). End to access edge media protection described in this document is not a substitute for end-to-end media protection. A user agent requests end-to-access-edge media protection by including a "a=3D3ge2ae" SDP attribute at session setup. If this attribute is not included, then Dawes Expires December 17, 2010 [Page 4] =0C Internet-Draft Media Security Parameter June 2010 end-to-end protection is expected by the user agent and protection MUST NOT fall back to end-to-access-edge protection. 1.1.2. DTLS-SRTP DTLS-SRTP is described in RFC 5763 [8], which shows the basic message flow in Figure 1. The DTLS handshake takes place when Bob receives the initial INVITE request. Alice uses the source IP address of the DTLS "hello" message (3) as the destination address for "hello" message (4) even though Bob does not provide a contact address until the 200 OK message (8). Alice Proxies Bob |(1) INVITE | | |---------------->| | | |(2) INVITE | | |----------------->| | |(3) hello | |<-----------------------------------| |(4) hello | | |----------------------------------->| | |(5) finished | |<-----------------------------------| | |(6) media | |<-----------------------------------| |(7) finished | | |----------------------------------->| | |(8) 200 OK | | |<-----------------| |(9) 200 OK | | |<----------------| | | |(10) media | |<---------------------------------->| |(11) ACK | | |----------------------------------->| Message (1): INVITE Alice -> Proxy Figure 1: Security capability exchange message flow In some networks, media packets are blocked between Alice and Bob until Alice receives the 200 (OK) message 9, which blocks the DTLS handshake until after Alice receives message (9). Media will not be successfully exchanged unless the DTLS handshake is re-attempted after message (9) 200 OK. Even if the handshake is re-attempted, the Dawes Expires December 17, 2010 [Page 5] =0C Internet-Draft Media Security Parameter June 2010 media will be clipped until the handshake is complete. 1.1.3. SDP Capability Negotiation SDP capability negotiation is described in draft-ietf-mmusic-sdp-capability-negotiation [9] and describes sending multiple potential SDP combinations as an offer, such that a user agent can offer a choice of media security alternatives in the body of an initial INVITE request. However, the caller UA has no prior knowledge of whether media plane security setup will succeed and in many cases it will fail or cause a lengthy delay while the user agent re-attempts, for example using a different IP access network. 1.1.4. Motivations for RFC 3329 RFC3329 describes why security is needed to protect SIP signalling from man-in-the-middle attacks, and to accomodate the expected wide variation in security mechanism support by SIP entities. The media plane requires similar protection and exchange of security capabilities, for example to prevent eavesdropping in environments such as public wireless access networks that have no inherent security. For the media plane security mechanism defined by this document, the cryptographic key is in plain text in SDP, therefore signalling SHOULD be protected e.g. using the security mechanism negotiation described by RFC 3329 [1] From john.elwell@siemens-enterprise.com Tue Jun 15 07:27:57 2010 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 CDB293A6919 for ; Tue, 15 Jun 2010 07:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_50=0.001, NORMAL_HTTP_TO_IP=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 LCmSxEWsGGfZ for ; Tue, 15 Jun 2010 07:27:56 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 743C83A688D for ; Tue, 15 Jun 2010 07:27:55 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-515200; Tue, 15 Jun 2010 16:27:58 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id A806723F0278; Tue, 15 Jun 2010 16:27:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 15 Jun 2010 16:27:59 +0200 From: "Elwell, John" To: "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Tue, 15 Jun 2010 16:27:57 +0200 Thread-Topic: Reason In responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKogA9AH9jABpml4wA== Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) 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, 15 Jun 2010 14:27:57 -0000 =20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: 07 June 2010 06:59 > To: Elwell, John; dispatch@ietf.org > Subject: AW: Reason In=20 > responses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Hi John, > Thank you for your comments: > Here are my view. >=20 > REQ-1: > I think that REQ-1 is still a justification, because not each=20 > Operator will use SIP-T for tunnelling purposes. > If you pass an untrusted domain SIP-T should not part,=20 > because it could include restricted numbers or other=20 > information that should not be presented to untrusted networks. >=20 > Also only for passing the Q.850 Cause code to encapsulate the=20 > whole ISUP is a little over dimensioned. > The SIP-T MIME can be lost due to the interdomain trust=20 > relation ships which the Reason header cannot. >=20 > For in an multi carrier/service provider environment like=20 > Germany is, it will not be secure that each operator will=20 > support SIP-T.=20 [JRE] This helps to explain why SIP-T is not sufficient. IF SIP-T requires = you to include additional information that you may not want to include when= going outside a domain, that would be a reason for requiring a different s= olution. This was not made clear before. John >=20 > REQ-2 > It must be possible to provide an accurate indication to a=20 > UAC, so that the UAC can provide a suitable indication to the=20 > user. >=20 > So that is the proposal for REQ-2. >=20 > REQ-3=20 > A UA may have the ability to display ISUP specific release=20 > causes or > show a equivalent text. >=20 > So that would be sufficient enough for REQ-3. If people would=20 > like to see such text. >=20 > REQ-3/4 > Your comment with regard to the type of UA is correct. I=20 > tried to satisfy people. The fact is that is not intended to=20 > include the Q.850 cause by an SIP end device. So the=20 > conclusion is changing REQ-3 and deleting REQ-4. >=20 > So now I would like to ask the people which requirements they=20 > would like to see in the draft. > As I understand John he sees only one (REQ-2) >=20 > I propose REQ-1, -2 and -3. >=20 > Opinions? >=20 > Thank you and Best Regards >=20 > Roland >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Roland Jesske > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628-2766 (Tel.) > +49 521 9210-3753 (Fax) > +49 171 8618-445 (Mobil) > E-Mail: mailto:r.jesske@telekom.de > http://www.telekom.com =20 >=20 > Erleben, was verbindet.=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 >=20 > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > nicht jede E-Mail drucken. >=20 > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Gesendet: Dienstag, 18. Mai 2010 21:37 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: Reason In=20 > responses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Roland,=20 >=20 > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > > Sent: 18 May 2010 15:57 > > To: Elwell, John; dispatch@ietf.org > > Subject: AW: Reason In=20 > > responses(draft-jesske-dispatch-reason-in-responses-02) > >=20 > > Hi John, > > Thank you for your comments.=20 > > It was asked to split the draft into requirements and at=20 > > least procedures. > >=20 > > You are right that within the requirements draft is more that=20 > > requirements. It is also the motivation, justification and=20 > > examples. I can change the title if people are happy with it.=20 > > Question is if such a draft is also needed as RFC or if it=20 > > only seen as a temporary document during the discussion. > [JRE] I was not proposing a title change, and I have no=20 > problem combining motivation with requirements, although I do=20 > feel the examples look too much like solution and are=20 > unnecessary. Although some people asked you to split the=20 > draft, in my opinion it was wasted effort, but it is done now. >=20 > >=20 > > With regard to REQ-1 I propose the following re-wording: > >=20 > > It should be possible to support within native SIP=20 > > environment PSTN-SIP-PSTN scenarios where the reason of a=20 > > call release can be transferred though the SIP domain > > without any loss of information and no change of reason. > >=20 > > I think this was discussed lengthy during the last meeting=20 > > and email discussion. > > Not each PSTN GW will support ISUP MIME encapsulation. At=20 > > least the 3GPP IMS has no SIP. The IMS is not using SIP-T. > [JRE] I don't think the new wording makes any difference.=20 > SIP-T is a means for tunnelling a Q.850 cause through a=20 > native SIP domain. The IETF already defines SIP-T as the=20 > solution, and if this solution is not sufficient, you need to=20 > cite reasons why not and identify a requirement that cannot=20 > be met using SIP-T. Just saying that IMS does not use SIP-T=20 > doesn't sound like a sufficient reason to me, because clearly=20 > IMS could be made to use SIP-T. >=20 > To be clear, I am not saying that the Reason header field=20 > should not be used in this situation, if the header field is=20 > defined for use in responses in general in order meet other=20 > requirements. I am simply saying that REQ-1 is not sufficient=20 > justification for allowing the Reason header field in=20 > responses, since REQ-1 can be satisfied using an existing mechanism. >=20 >=20 > >=20 > > REQ-2 and REQ-3 > > Yes it looks similar. > >=20 > > REQ-3 was added because it was seen from user device=20 > > perspective that the Device have the possibility to show the=20 > > Q.850 cause but that such a End Device does not include Q.850=20 > > causes. Of course a MGC should have this possibility. > >=20 > > I would be happy to shrink REQ-2 and 3 to your proposed text. > >=20 > > REQ-2 > > It must be possible to provide an accurate indication to a=20 > > UAC, so that the UAC can provide a suitable indication to the=20 > > user. Whether this be an announcement, a textual message, an=20 > > icon, a flashing lamp, a tone, a vibration, an odour or=20 > > whatever, is a user interface matter. > [JRE] I did not intend the second sentence to be part of the=20 > requirement - it was just for illustration of why the=20 > existing text, which focused on textual display, was inadequate. >=20 > >=20 > > REQ-4 was the consequence of REQ-3 where we do not allow the=20 > > inclusion of a Q850 cause by a end device. > >=20 > > So the trick is not allow the SIP end device to include a=20 > > Q850 cause and in some certain cases to allow an service=20 > > provider controlled application server to include a Reason=20 > > header with a Q.850 cause. But it should not be done=20 > > generally by SIP applications. So normally a ISUP=20 > > implementation will use ISUP causes but not SIP implementations. > > But there are SIP Application servers out in the world that=20 > > will have a ISUP application (or ISUP like application that=20 > > reacts and behaves as within a ISUP network). > [JRE] I found REQ-3 rather confusing. On re-reading it, the=20 > first sentence is a requirement concerning reception, and the=20 > second sentence seems (if I understand correctly) to be a=20 > statement about sending. Assuming my understanding is=20 > correct, making a statement, within a requirement, that=20 > something is out of scope seems to suggest it is not part of=20 > the requirement. >=20 > In addition, the way SIP is specified, there is no real=20 > distinction between different types of UA. In other words,=20 > SIP procedures for UAs apply to UAs in general, not to=20 > specific types of UA like ASs. So writing a requirement that=20 > tries to distinguish between different types of UA does not=20 > seem to make sense. >=20 > >=20 > > Question is now how to proceed further. > >=20 > > Are people happy to have the documents split or put again=20 > > together with striking out the examples ect? > > Or to have the documents as they are with some transfer of=20 > > text to the draft-jesske-dispatch-reason-in-responses-02 draft? > [JRE] I don't have a strong opinion about document structure,=20 > although my personal preference would have been to leave it=20 > as one document, as it was originally. My main concern is=20 > trying to come up with a meaningful set of requirements, and=20 > in my opinion it reduces to a single requirement - being able=20 > to convey a Q.850 cause from PSTN (or similar) to a UAC so=20 > that the UAC can render meaningful information to the user. >=20 > John >=20 >=20 > >=20 > > Comments? > >=20 > > Thank you and Best Regards > >=20 > > Roland > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Gesendet: Donnerstag, 13. Mai 2010 09:24 > > An: Jesske, Roland; dispatch@ietf.org > > Betreff: RE: Reason In=20 > > responses(draft-jesske-dispatch-reason-in-responses-02) > >=20 > > Roland, > >=20 > > In my view, there is a simple requirement to convey Q.850=20 > > causes in SIP response messages, so that the UAC will receive=20 > > a more accurate indication of the reason for rejection when=20 > > rejection comes from PSTN. The cause mapping table helps to=20 > > illustrate this. This is not rocket science, and I am=20 > > disappointed that we have not found a quick way of=20 > > dispatching this and just getting the work done. In my=20 > > opinion the split into separate documents was unnecessary=20 > > (take as an example the recently-published RFC 5876, which=20 > > combines motivation and solution in one document), but it has=20 > > been done now. Unfortunately I don't think it has moved us=20 > > any further forward. > >=20 > > I don't think the requirements in section 3 are particularly=20 > > well expressed. REQ-1 can already be met by tunnelling in=20 > > accordance with SIP-T. I would not expect the IETF to provide=20 > > a new solution specifically for that requirement. > >=20 > > I think REQ-2 and REQ-3 boil down to the same thing - it must=20 > > be possible to provide an accurate indication to a UAC, so=20 > > that the UAC can provide a suitable indication to the user.=20 > > Whether this be an announcement, a textual message, an icon,=20 > > a flashing lamp, a tone, a vibration, an odour or whatever,=20 > > is a user interface matter. > >=20 > > I also find REQ-4 rather problematic. If we have a solution=20 > > for PSTN, we would also have a solution for some other form=20 > > of gateway into a domain that provides a "PSTN-like service".=20 > > Unfortunately, if you try to bring this out as a separate=20 > > requirement, it raises the question of what exactly is this=20 > > "PSTN-like service", and if it is somehow SIP-based, why it=20 > > needs to be "PSTN-like", and so on. > >=20 > > Basically I think there is only a single requirement here -=20 > > provision of a correct indication to a UAC when rejection=20 > > comes from the PSTN. I think that is a reasonable requirement=20 > > and we should just go ahead and do it, rather like we did=20 > > with RFC 5876 when we extended the range of messages that=20 > > PAI/PPI could be used in. > >=20 > > I find the statement in REQ-3 "A inclusion of [Q.850] causes=20 > > is out of scope." very strange. I thought the whole idea was=20 > > to convey Q.850 causes, so why say they are out of scope? I=20 > > assume this is some sort of typo. > >=20 > > I think one of the consequences of deciding to split=20 > > requirements and solution into separate drafts is that the=20 > > requirements draft has to stick to motivation and=20 > > requirements. I find too much in the draft (particularly the=20 > > examples) that smells of solution. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 > R.Jesske@telekom.de > > > Sent: 13 May 2010 03:05 > > > To: dispatch@ietf.org > > > Subject: Re: [dispatch] Reason In responses=20 > > > (draft-jesske-dispatch-reason-in-responses-02) > > >=20 > > > Dear all,=20 > > > I have asked for comments on the two drafts mentioned below.=20 > > > So far I didn't get any. Does that mean that people are happy=20 > > > now with the content and we could proceed with it?=20 > > >=20 > > > Thank you and Best Regrads=20 > > >=20 > > > Roland=20 > > >=20 > > >=20 > > > _____________________________________________=20 > > > Von: Jesske, Roland =20 > > > Gesendet: Donnerstag, 8. April 2010 09:46=20 > > > An: dispatch@ietf.org=20 > > > Betreff: Reason In responses=20 > > > (draft-jesske-dispatch-reason-in-responses-02)=20 > > >=20 > > > Dear all,=20 > > > During the discussion concerning the Reason header field in=20 > > > Responses I was asked to split the document into an=20 > > > requirements part and an protocol part. > > >=20 > > > So please feel free to comment on the drafts.=20 > > >=20 > > > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-respo > > > nses-02=20 > > > > > onses-02> =20 > > >=20 > > > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-r > > > esponses-00=20 > > > > > responses-00> =20 > > >=20 > > > Best regards=20 > > >=20 > > > Roland Jesske=20 > > >=20 > > >=20 > > > Deutsche Telekom Netzproduktion GmbH=20 > > > Zentrum Technik Einf=FChrung=20 > > > Roland Jesske=20 > > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > > > +49 6151 628-2766 (Tel.)=20 > > > +49 521 9210-3753 (Fax)=20 > > > +49 171 8618-445 (Mobil)=20 > > > E-Mail: r.jesske@telekom.de =20 > > > www.telekom.com =20 > > >=20 > > > Erleben, was verbindet.=20 > > >=20 > > > Deutsche Telekom Netzproduktion GmbH=20 > > > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 > > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > > > Albert Matheis, Klaus Peren=20 > > > Handelsregister: Amtsgericht Bonn HRB 14190=20 > > > Sitz der Gesellschaft: Bonn=20 > > > USt-IdNr. DE 814645262=20 > > >=20 > > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > > > nicht jede E-Mail drucken.=20 > > >=20 > > >=20 > > >=20 > >=20 > = From fluffy@cisco.com Tue Jun 15 07:28:49 2010 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 C15D03A690F for ; Tue, 15 Jun 2010 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.971 X-Spam-Level: X-Spam-Status: No, score=-108.971 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, 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 ilXbBeyXpmk1 for ; Tue, 15 Jun 2010 07:28:48 -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 6D70F3A688D for ; Tue, 15 Jun 2010 07:28:48 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,420,1272844800"; d="scan'208";a="212634472" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 15 Jun 2010 14:28:52 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o5FESoVE012398; Tue, 15 Jun 2010 14:28:51 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Tue, 15 Jun 2010 08:28:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9A31589C-D364-4DB8-AA09-78A6772A8A16@cisco.com> References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> <1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> <4C10E050.5090102@cisco.com> To: Christer Holmberg X-Mailer: Apple Mail (2.1078) Cc: DISPATCH list Subject: Re: [dispatch] Final Charter for Session-ID? 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, 15 Jun 2010 14:28:49 -0000 I'm not following what you mean but it seems like this might lead to a = workable definition. Can you propose something a bit more specific? On Jun 10, 2010, at 6:57 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > Isn't the linkage the fact that C is the person A addressed for this = specific session? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org=20 >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 10. kes=E4kuuta 2010 15:54 >> To: Muthu ArulMozhi Perumal (mperumal) >> Cc: DISPATCH list >> Subject: Re: [dispatch] Final Charter for Session-ID? >>=20 >>=20 >>=20 >> Muthu ArulMozhi Perumal (mperumal) wrote: >>> Here is an initial attempt: >>>=20 >>> If there is a dialog between A and B then A and B are in a session. >>> If there is a dialog between A and B and a dialog between B=20 >> and C at=20 >>> the same time then A, B and C are in a session. >>> More generally, if two or more participants are part of a session S=20= >>> and at the same time there is a dialog between one of the=20 >> participants=20 >>> of S and another participant Z who is not part of S, then S=20 >> (union) Z=20 >>> is a session. >>=20 >> The above just reiterates the problem that Cullen was raising. >> Just because B has a dialog with A and a dialog with C does=20 >> not mean that there is a session between A and C. A gateway=20 >> provides a perfect example of that. >>=20 >> There needs to be some semantic link between the dialogs. The=20 >> question is defining what sorts of semantic links should be=20 >> used to share a session id. >>=20 >> Thanks, >> Paul >>=20 >>> I think this would cover most of SBC, 3PCC an app server=20 >> cases. People=20 >>> can add cases like park/retrieve if they think they should be=20 >>> considered as part of a single session. >>>=20 >>> Muthu >>>=20 >>> |-----Original Message----- >>> |From: dispatch-bounces@ietf.org=20 >> [mailto:dispatch-bounces@ietf.org] On >>> Behalf >>> |Of Cullen Jennings (fluffy) >>> |Sent: Wednesday, June 09, 2010 8:23 PM >>> |To: DISPATCH list >>> |Subject: Re: [dispatch] Final Charter for Session-ID? >>> | >>> |I have a problem with this proposed charter. >>> | >>> |On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: >>> | >>> |> >>> |> The definition of a higher-layer "session" of the same=20 >> "message-flow" >>> is >>> |not defined by SIP when it involves a B2BUA, and is difficult to >>> normatively >>> |define in practice. For the purposes of this WG charter's=20 >> scope, two >>> or >>> |more dialogs of a B2BUA are correlated under any conditions where=20= >>> |correlation might aid troubleshooting, by identifying them as=20 >>> |belonging >>> to >>> |the same higher-level session. Any solution documents from this=20 >>> |working group may expand or constrain the scope of their=20 >> mechanism's >>> correlation, if >>> |the working group so decides. >>> | >>> |I think the above text is way too vague and impossible to=20 >> reduce to=20 >>> |engineering practice. If you have 10 calls going to a PSTN=20 >> GWs that=20 >>> |is having voice quality problems, clearly having all of=20 >> them grouped >>> together >>> |is useful in debugging. Yet I doubt we want all the calls from a=20 >>> |given >>> PSTN >>> |GW to have the same correlation ID. Our lack of any solid=20 >> definition=20 >>> |of >>> what >>> |it is we are trying to correlate is a strong indication to=20 >> me that we >>> have >>> |not yet come to any consensus about what the problem is=20 >> this WG would >>> be >>> |trying to fix. >>> | >>> |I would like to see a WG charted in this area but I would=20 >> expect the >>> IESG to >>> |more or less laugh at a problem statement that reduced down to "uh >>> might be >>> |useful for debuggin". Can some people please try and propose a more >>> concrete >>> |definition of when two sip dialogs will be correlated? >>> | >>> |Cullen >>> | >>> |_______________________________________________ >>> |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 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Tue Jun 15 07:36:43 2010 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 C6E5E3A6A2F for ; Tue, 15 Jun 2010 07:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.06 X-Spam-Level: X-Spam-Status: No, score=-110.06 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kzyg8Fl+0Uk0 for ; Tue, 15 Jun 2010 07:36:42 -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 AE2AB3A68D4 for ; Tue, 15 Jun 2010 07:36:42 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADYsF0yrR7H+/2dsb2JhbACednGlR5ouhRoEg08 X-IronPort-AV: E=Sophos;i="4.53,420,1272844800"; d="scan'208";a="226530006" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2010 14:36:47 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5FEajpo000053; Tue, 15 Jun 2010 14:36:46 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4C15C46D.3010504@ericsson.com> Date: Tue, 15 Jun 2010 08:36:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <4C1224FF.5050105@ericsson.com> <4C15C46D.3010504@ericsson.com> To: "Dale R (Dale) WORLEY" X-Mailer: Apple Mail (2.1078) Cc: Robert Sparks , DISPATCH list Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs 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, 15 Jun 2010 14:36:44 -0000 Let Mary and I try and to reserver 30 minutes or more for Alert-Info = URN. If ALert URN is a WG by that point, it can run it as a very short = WG meeting and if is not a WG we can use the time to discuss how to get = to being a WG. We still need to sort out the agenda but I don't foresee = a problem with this.=20 On Jun 13, 2010, at 11:55 PM, Gonzalo Camarillo wrote: > Hi, >=20 > if you need face-to-face time for this, go ahead talk to the DISPATCH > chairs so that you can either get a slot within the DISPATCH session = or, > alternatively, have an ad-hoc meeting. If we managed to charter the WG > in time, we would have a WG meeting instead. >=20 > Cheers, >=20 > Gonzalo >=20 > On 14/06/2010 5:37 AM, WORLEY, Dale R (Dale) wrote: >> ________________________________________ >> From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] >>=20 >> yes, Mary's description is correct. The process is as follows. Once = we >> agreed on the charter, I requested the IESG to review it. This = charter >> will be discussed in the next IESG telechat (the coming Thursday), >> actually. Once the IESG is happy with it, the next step will be to = have >> an IETF-wide review. After that, we will be able to charter the WG. >>=20 >> In any case, as we have said a number of times, proponents of a >> particular piece of work should not stop working on it while we = charter >> their WG. They are encouraged to continue making progress in parallel >> with the chartering process. >> ________________________________________ >>=20 >> That is all fine, but what are the implications regarding getting a = time slot at Maastricht? There seem to be two choices: a slot within = Dispatch, or a separately scheduled Salud session. What we do not want = to get stuck with is not being able to get time in Dispatch (because a = charter has been proposed) and not being able to get a separate session = (because the charter hasn't gone through all the approval steps), as = that would prevent any session at Maastricht. >>=20 >> Dale >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Tue Jun 15 10:23:14 2010 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 E76483A687C for ; Tue, 15 Jun 2010 10:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.85 X-Spam-Level: X-Spam-Status: No, score=-108.85 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 C81b-9s82gK8 for ; Tue, 15 Jun 2010 10:23:13 -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 1A2D53A6852 for ; Tue, 15 Jun 2010 10:23:11 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEtUF0yrR7Ht/2dsb2JhbACedHGmWpotglmCQQSDTw X-IronPort-AV: E=Sophos;i="4.53,421,1272844800"; d="scan'208";a="226572754" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2010 17:23:15 +0000 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.14.3) with ESMTP id o5FHNENB018261; Tue, 15 Jun 2010 17:23:14 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Tue, 15 Jun 2010 11:23:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <33870CEC-3737-4070-8880-18ED4818D82F@cisco.com> To: Peter Musgrave X-Mailer: Apple Mail (2.1078) Cc: DISPATCH list Subject: [dispatch] VIPR - relation to public ENUM text 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, 15 Jun 2010 17:23:15 -0000 Thanks - I changed that a little bit and put it in the updated version. On Jun 2, 2010, at 12:49 PM, Peter Musgrave wrote: > How about: >=20 > "The essential characteristic of ViPR is establishing authentication > by PSTN reachability and not by e.g. direct reference to ENUM > databases or other assertions of PSTN number ownership. Elements such > as public ENUM may be employed indirectly as part of assessing the > PSTN reachability but no direct interaction with ENUM will be > required. " >=20 > Peter >=20 > On Wed, Jun 2, 2010 at 2:35 PM, Cullen Jennings = wrote: >>=20 >> I kept trying to write something about the relation of ViPR to ENUM = but it kept coming out sounding like public ENUM had failed - which was = not really what I wanted to say so I eventually deleted it. If someone = had some good text about ENUM, would be nice to add it. >>=20 >> I view infrastructure and carrier ENUM as somewhat unrelated to this = but public ENUM is related. However, ENUM talks about how to query the = database, but it is somewhat silent on how data gets in the database. = How does the database authorize that someone is authoritative for a = number and can put write a record into the ENUM database. VIPR is more = about that side of the problem. >>=20 >> And +1 to Paul's answers of the other questions .... >>=20 >> On Jun 1, 2010, at 12:28 PM, Peter Musgrave wrote: >>=20 >>> Hi Cullen, >>>=20 >>> Does the charter need to say anything explicitly about not relying = on >>> any of the work which uses ENUMs in DNS as a way of associating SIP >>> endpoints and IP addresses? >>>=20 >>> AFAIK ViPR is about *using* a SIP call to determine a path to the >>> endpoint (however that happens to work). >>>=20 >>> Does the charter need to stipulate that the mapping from a PSTN = number >>> to a SIP device is a one-to-one mapping? Does there need to be text >>> about how multiple endpoints which are behind a border device (and = all >>> appear as the same PSTN number) are to be handled?. >>>=20 >>> ViPR so far describes an "edge-device" approach. Is the charter >>> restricted to this approach? >>>=20 >>> Thanks, >>>=20 >>> Peter Musgrave >>>=20 >>>=20 >>>=20 >>> On Tue, Jun 1, 2010 at 12:55 PM, Cullen Jennings = wrote: >>>>=20 >>>> I've been talking to a lot of people about the VIPR drafts - here = is a first cut of a proposal for a WG that could do this. I'm sure the = charter proposal needs a bunch of work but I wanted to get the = discussion rolling on the list. >>>>=20 >>>> Thanks, Cullen >>>>=20 >>>> (PS - this is sent in my individual contributor role. Take all my = posts about VIPR to be in my individual role not my co-chair role) >>>>=20 >>>> ------------------------------------------------------- >>>>=20 >>>> ViPR Charter Proposal (Version 0) >>>>=20 >>>> WG Name: Verification Involving PSTN Reachability (VIPR) >>>>=20 >>>> There are two globally deployed address spaces for communications = that more than a billion people use on a daily basis. They are phone = numbers and DNS rooted address such as web servers and email addresses. = The federation design of SIP is primarily designed for email style = addresses yet a large percentage of SIP deployments primarily use phone = numbers for identifying users. The goal of this working group is to = allows people to use SIP to federate over the the internet while still = using phone numbers to identify the person they wish to communicate = with. >>>>=20 >>>> The VIPR WG will address this problem by developing a peer to peer = based approach to finding SIP domains that claim to be responsible for a = given phone number and the WG will design validation protocols to ensure = a reasonable likelihood that a given domain actually is responsible for = the phone number. One initial validation protocol will be based on a = domain being able to prove it received a particular phone call over the = PSTN based on both sides knowing the start and stop times of that call. = Other validation schemes, such as examining fingerprints or watermarking = of PSTN media, to show that a domain received a particular PSTN phone = call may be considered by the working group. To help mitigate SPAM over = SIP issues, the WG will define an token based authorization scheme so = that domain using SIP to federate can choose to check that incoming SIP = calls are from a domain that successfully validated a phone number. >>>>=20 >>>> The problem statement and some possible starting points for = solutions are further desired in the following internet drafts which = shall form the bases of the WG documents: >>>> draft-rosenberg-dispatch-vipr-overview >>>> draft-rosenberg-dispatch-vipr-reload-usage >>>> draft-rosenberg-dispatch-vipr-pvp >>>> draft-rosenberg-dispatch-vipr-sip-antispam >>>>=20 >>>> The working group will carefully coordinate with the security area, = O&M area, as well as the appropriate RAI WG including sipcore and = p2psip. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>=20 >>=20 >>=20 >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >>=20 >>=20 >>=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Tue Jun 15 10:23:29 2010 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 238D03A68BC for ; Tue, 15 Jun 2010 10:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.028 X-Spam-Level: X-Spam-Status: No, score=-110.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 nfNJEJvziMid for ; Tue, 15 Jun 2010 10:23:28 -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 5ADFC3A68B7 for ; Tue, 15 Jun 2010 10:23:28 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIdUF0yrR7Ht/2dsb2JhbACedHGmYpothRoEg08 X-IronPort-AV: E=Sophos;i="4.53,421,1272844800"; d="scan'208";a="545309870" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 15 Jun 2010 17:23:32 +0000 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.14.3) with ESMTP id o5FHNENC018261; Tue, 15 Jun 2010 17:23:32 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4C06A36B.3090103@acm.org> Date: Tue, 15 Jun 2010 11:23:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C06A36B.3090103@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1078) Cc: DISPATCH list Subject: [dispatch] (VIPR) - VAP in or out? 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, 15 Jun 2010 17:23:29 -0000 On Jun 2, 2010, at 12:31 PM, Marc Petit-Huguenin wrote: >>=20 >> The problem statement and some possible starting points for solutions = are further desired in the following internet drafts which shall form = the bases of the WG documents: >> draft-rosenberg-dispatch-vipr-overview >> draft-rosenberg-dispatch-vipr-reload-usage >> draft-rosenberg-dispatch-vipr-pvp >> draft-rosenberg-dispatch-vipr-sip-antispam >=20 > VAP is not listed here. Is it an oversight or is it because the WG = will work > only on interoperability between ViPR servers? I could go either way on VAP. On one hand, the minimal thing we need to = standardize to have interoperability between domain is just the above = stuff without VAP. On the other hand, VAP is a very simple way to = modularize what is happening inside a domain. VAP allows information = about PSTN call to be given to the server doing the VIPR stuff and = allows the VIPR server to tell routing engines and PBX inside the domain = about new routes.=20 I'd be interested in hearing what other thing. It's easy to add = something like VAP to the charter.=20 From fluffy@cisco.com Tue Jun 15 10:23:38 2010 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 3D9853A6852 for ; Tue, 15 Jun 2010 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.799 X-Spam-Level: X-Spam-Status: No, score=-108.799 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 pC24jSN4BZSk for ; Tue, 15 Jun 2010 10:23:36 -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 D7FE63A68B7 for ; Tue, 15 Jun 2010 10:23:36 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEtUF0yrR7Ht/2dsb2JhbACedHGmWpotglmCQQSDTw X-IronPort-AV: E=Sophos;i="4.53,421,1272844800"; d="scan'208";a="226572859" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 15 Jun 2010 17:23:41 +0000 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.14.3) with ESMTP id o5FHNEND018261; Tue, 15 Jun 2010 17:23:40 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB49@srvxchg> Date: Tue, 15 Jun 2010 11:23:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <44DA64DC-00F6-416C-8300-3373B9FA4076@cisco.com> References: <76AC5FEF83F1E64491446437EA81A61F7CF49FAB49@srvxchg> To: Jean-Francois Mule X-Mailer: Apple Mail (2.1078) Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 15 Jun 2010 17:23:38 -0000 Hi - many thanks for the great comments - few comments inline but I = agree with all your points and tried to update the charter = appropriately.=20 On Jun 2, 2010, at 2:59 PM, Jean-Francois Mule wrote: > Hi, >=20 > I support this proposed work to be taken by IETF under a new working = group. There are certainly concrete deliverables that would merit IETF = consensus to spur multi-vendor interoperability. >=20 > A few comments below, mostly to help bash the proposed charter. >=20 > Jean-Francois. >=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On Behalf Of Cullen Jennings >> Sent: Tuesday, June 01, 2010 10:55 AM >> To: DISPATCH list >> Subject: [dispatch] Charter Proposal: Verification Involving PSTN >> Reachability (VIPR) >>=20 >>=20 >> I've been talking to a lot of people about the VIPR drafts - here >> is a first cut of a proposal for a WG that could do this. I'm sure >> the charter proposal needs a bunch of work but I wanted to get the >> discussion rolling on the list. >>=20 >> Thanks, Cullen >>=20 >> (PS - this is sent in my individual contributor role. Take all my >> posts about VIPR to be in my individual role not my co-chair role) >>=20 >> ------------------------------------------------------- >>=20 >> ViPR Charter Proposal (Version 0) >>=20 >> WG Name: Verification Involving PSTN Reachability (VIPR) >>=20 >> There are two globally deployed address spaces for communications >> that more than a billion people use on a daily basis. They are >> phone numbers and DNS rooted address such as web servers and email >> addresses. The federation design of SIP is primarily designed for > ^^^^^^^^^^^^^^^^^^^^^^^^ > Given some folks talk about SIP federations in the context of = speermint (http://tools.ietf.org/html/rfc5486#section-5) and I don't = think this is what you mean here, this choice of terms may not be the = best. As much as some folks disagree on the worthiness of the output of = speermint, at least SIP federations are described there. Would = recommend clarifying this somehow. yah - agree. "Federation" means a lot of things but conflicting with = speermint terminology seems like a bad plan. I'll try and rephrase in = terms of "inter domain calling"=20 >=20 >> email style addresses yet a large percentage of SIP deployments >> primarily use phone numbers for identifying users. The goal of this >> working group is to allows people to use SIP to federate over the > ^^^^^^^^^^^^^^^^^^^ > my understanding is that those people would not only use SIP but some = other smarts to put some stuff in DHTs to enable PSTN reachability = verification. This implies that the solution solely relies on SIP. May = want to expand or clarify, or else qualify the sentence further. yep ... I think this works for more than just SIP >=20 >> the internet while still using phone numbers to identify the person >> they wish to communicate with. >>=20 >=20 >=20 >> The VIPR WG will address this problem by developing a peer to peer >> based approach to finding SIP domains that claim to be responsible > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That may open a rathole: what does it mean to be responsible for a = given phone number (worst case, Rich Shockey will chime in and will = muddy this more, or John Elwell will claim this should have been in = speermint but it cannot be found there...). >=20 > Do you mean any SIP Service Provider = (http://tools.ietf.org/html/rfc5486#section-3.9) on the signaling path = of a SIP invite or dialog-initiating request for that telephone number? = Do you mean the SIP domain responsible for the last hop before the SIP = UA? Both? Or is it the latter with the pre-requisite that PSTN = connectivity is required somehow? It's was deliberately a bit vague. The real goal is to get the best = approximation we can of the administrative domain who controls the phone = that rings when you dial that number. The whole concept of ownership of = a phone number is so muddled that trying to use owner is clearly = useless. It's very unclear if my cell phone number is owned by me (I can = LNP to wherever I want and Cisco lets me take on termination of my = employment), to Cisco (they pay the bill), to AT&T, to Neustar, or to = some government, or any of the other parties that could cause it not to = work. I think the best definition we can come up with of responsible is = an administrative domain that is always involved in the call signaling = of a PSTN call to that phone number. I tired to clear up in the charter = a bit but this is going to need a bunch of people to help fine tune = text.=20 >=20 >> for a given phone number and the WG will design validation >> protocols to ensure a reasonable likelihood that a given domain >> actually is responsible for the phone number. One initial >> validation protocol will be based on a domain being able to prove >> it received a particular phone call over the PSTN based on both >> sides knowing the start and stop times of that call. Other > This last sentence is advocating one specific solution. =20 > I think the VIPR drafts are powerful and this may be part of a working = solution. But at this stage in the WG charter definition, would it be = preferable to say something like: > Some validation protocols may be based on additional knowledge = gathered around a SIP call, for example, the ability to prove a call was = received over the PSTN based on start and stop times. >=20 > It leave things open and welcomes other proposals. It also does not = preclude the validation protocol you have documented. Fair enough - I changed draft charter to you suggested text. If we = think there is a reasonable chance that we might not do this start/stop = time validations, then this change makes sense but if we are pretty = certain we will do this approach, then I generally prefer making the = charters as specific as possible.=20 >=20 >> validation schemes, such as examining fingerprints or watermarking >> of PSTN media, to show that a domain received a particular PSTN >> phone call may be considered by the working group.=20 > These are additional examples that must be part of the same bucket as = the one before imo. Currently it reads that PSTN+start+stop is the = initial one, others may be considered later. =20 > I have no preference and like the elegance of the approach in some the = VIPR drafts. But the charter should make clear that the WG will decide = this. OK >=20 >> To help mitigate >> SPAM over SIP issues, the WG will define an token based >> authorization scheme so that domain using SIP to federate can >> choose to check that incoming SIP calls are from a domain that >> successfully validated a phone number. > Same here, you state a solution to a pb. I would prefer to have a = requirement in the charter that mandates the WG comes up with a method = to help mitigate SPIT by ensuring that a domain using SIP can validate = incoming calls are indeed from a domain that successfully validated the = TN. Ok - changed to say that.=20 >=20 >=20 >> The problem statement and some possible starting points for >> solutions are further desired in the following internet drafts >> which shall form the bases of the WG documents: >> draft-rosenberg-dispatch-vipr-overview >> draft-rosenberg-dispatch-vipr-reload-usage >> draft-rosenberg-dispatch-vipr-pvp >> draft-rosenberg-dispatch-vipr-sip-antispam >>=20 >> The working group will carefully coordinate with the security area, >> O&M area, as well as the appropriate RAI WG including sipcore and >> p2psip. >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Tue Jun 15 10:24:49 2010 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 1DC513A6852 for ; Tue, 15 Jun 2010 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.711 X-Spam-Level: X-Spam-Status: No, score=-108.711 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 hl35MjdB2JiS for ; Tue, 15 Jun 2010 10:24:48 -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 3B3943A687C for ; Tue, 15 Jun 2010 10:24:48 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANNTF0yrR7Ht/2dsb2JhbACedHGmT5otglmCQQSDTw X-IronPort-AV: E=Sophos;i="4.53,421,1272844800"; d="scan'208";a="335353356" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2010 17:24:52 +0000 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.14.3) with ESMTP id o5FHNENF018261 for ; Tue, 15 Jun 2010 17:24:52 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Tue, 15 Jun 2010 11:24:51 -0600 Message-Id: To: DISPATCH list Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [dispatch] VIPR - proposed charter version 2 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, 15 Jun 2010 17:24:49 -0000 Thanks for all the comments on the list. Here is a revised version: (PS. If anyone else wants to edit, this is in SVN and glad to get anyone = write permission) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ViPR Charter Proposal (Version 2) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications that more than a billion people use on a daily basis. They are phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users. The goal of this working group is to enable inter-domains communications over the the internet, using protocol such as SIP, while still allowing people to use phone numbers to identify the person they wish to communicate with. The VIPR WG will address this problem by developing a peer to peer based approach to finding domains that claim to be responsible for a given phone number and validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, we use "responsible" to mean an administrative domain would would be at least one of the administrative domains that a PSTN call to this phone number would be routed to. Once the domain responsible for the phone number is found, existing protocols such as SIP and XMPP can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a SIP call, for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media, to show that a domain received a particular PSTN phone call may also be considered by the working group. The WG will select and standardize at least one validation scheme. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanisms to enable one domain to check that incoming SIP messages from a different domain are coming from a domain that successfully validated a phone number. The working group will define new SIP headers and option tags to enable this. The essential characteristic of ViPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The problem statement and some possible starting points for solutions are further discussed in the following internet drafts which shall form the bases of the WG documents: draft-rosenberg-dispatch-vipr-overview draft-rosenberg-dispatch-vipr-reload-usage draft-rosenberg-dispatch-vipr-pvp draft-rosenberg-dispatch-vipr-sip-antispam The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WG including sipcore and p2psip. From dworley@avaya.com Tue Jun 15 10:28:10 2010 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 1AA7B3A6887 for ; Tue, 15 Jun 2010 10:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_50=0.001, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymmm120tyvgQ for ; Tue, 15 Jun 2010 10:28:08 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id CA7FF3A687C for ; Tue, 15 Jun 2010 10:28:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,421,1272859200"; d="scan'208";a="20734173" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 15 Jun 2010 13:28:11 -0400 X-IronPort-AV: E=Sophos;i="4.53,421,1272859200"; d="scan'208";a="483651417" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jun 2010 13:28:10 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 15 Jun 2010 13:28:10 -0400 From: "WORLEY, Dale R (Dale)" To: "dispatch@ietf.org" Date: Tue, 15 Jun 2010 13:27:59 -0400 Thread-Topic: Conceptual proposal for extensibility of Alert-Info URNs Thread-Index: AQHLDLAZz4CvE4x2vE2wuJFs46Ydnw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 15 Jun 2010 17:28:10 -0000 [As I am the chair-elect for this topic, I now have to identify that I am proposing this as an individual contributor-elect.] This is a conceptual proposal for for specifying Alert-Info URNs. The problem that I am attacking is extensibility -- because the practical application of the Alert-Info URNs will be as successors of the ring tone and ringback tone implementations of innumerable existing telephone systems, we expect the uses of Alert-Info URNs to be subject to much extension. The primary problem is to provide a framework which allows such extensions to be implemented without damaging interoperability between systems whose Alert-Info usage has not been coordinated a priori. A secondary problem is to ensure that the framework can be implemented efficiently in practical situations. The basis of this proposal has been stolen from previous contributors to the Alert-Info work. Since this is a conceptual proposal, I am not particular about the syntax to be used -- the syntax shown here is just to illustrate the concepts. What I am proposing is a system of semantics; many variant syntaxes can be used to implement it with differing tradeoffs. * Terminology We say that a "specifier" sends an "indication" (a URN in an Alert-Info header) to a "renderer" which then "renders" a "signal" based on the indication to a human user. A "category" is a characteristic whose "values" can be used to classify indications. * Requirements and non-requirements Requirement A: Indications must be able to represent a wide variety of signals, which have many largely-orthogonal characteristics. (See draft-liess-dispatch-alert-info-urns-00 section section 2 for a partial list, and Paul Kyzivat's message for another partial list.) Requirement B: Indications include subsets which have distinctly different semantics, that is, they form disjoint "value spaces". For example, some indications should describe the semantics of the signaling situation whereas others should describe the audio characteristics of the signal. This implies that there is no single set of categories that can be used as independent coordinates of the value-space of indications. Requirement C: The set of indications must be able to support extensibility by a wide variety of organizations that are not coordinated with each other. Extensions must be able to: - add further values to any existing category - add further categories that are orthogonal to existing categories - semantically subdivide the meaning provided by any existing indication - add further "value spaces" of indications whose semantics are not related to existing indications, and thus, whose categories differ from and do not interact with existing categories Requirement D: An indication is transmitted from a specifier to a renderer, which must base its rendering decision only on the indication. In particular, there is no multi-message negotiation process or carrying of context from one indication to the next. Requirement E: The renderer may be customized in ways that limit the set of signals that it can render, or it may be provided with a set of signals that have uncommon semantics. (The canonical example is a UA for the hearing-impaired.) (By Requirement D, the renderer has no way of transmitting this fact to the specifier.) Requirement F: If the specifier and the renderer have designs that are properly coordinated, the indications must be able to reliably carry all extensions that are supported in the coordinated designs. Requirement G: In any situation, the renderer must be able to perform close to the best possible rendering that it could do even the specifier had specific knowledge of the renderer's capabilities. Non-Requirement H: In any situation other than that of Requirement F, we do not require the render to perform the best possible rendering. * Categories, values, and indicators There are a theoretically infinite number of categories. Each category is named by a word, such as: reason priority source duration The values of each category conceptually form a tree. The root of the tree is the universal, or most general, value. It is denoted by the the category name, and represents the universe of all possibilities. Each further subdivision of a value is specified by adding a hyphen and another word. Thus, within the category "state" we have values: state state-unknown state-waiting state-on.call state-away (Here we pretend '.' is a letter.) The first of these values specifies no specific information. The following values specify subdivisions of the semantic space. The value "state-waiting" can be further subdivided based on the importance of the call being waited upon: state-waiting-standard state-waiting-vip An indication is assembled by providing a sequence of values (which implicitly specify their categories), separated by colons, in order of importance. That is, the first value is the one that should be rendered as accurately as possible; within that constraint, the second value should be rendered as accurately as possible; etc. For example, we can assemble the following indications: an internal, priority call source-internal:priority-high priority call waiting reason-call.waiting:priority-high short Albanian auto-callback reason-auto.callback:duration-short:locale-al (The specific examples are taken from draft-liess-dispatch-alert-info-urns-00 section 4.5, the specific categories and values are adapted from Paul Kyzivat's message.) All of these indications are easily extensible. For instance, if Albania has two service providers with different signal tones, we could specialize the last indication into: short Albanian auto-callback, service provider A reason-auto.callback:duration-short:locale-al-sp.A short Albanian auto-callback, service provider B reason-auto.callback:duration-short:locale-al-sp.B Due to the rule that the earlier values in an indicator have more influence than latter values, there is a subtle difference between: source-internal:priority-high priority-high:source-internal in regard to which aspect of the indication it is more important to render. * Selecting the signal based on an indication Having defined a universe of indications with infinite extensibility, we now need to show that a practical device can interpret indications to select from a limited set of signals. To do this, I will describe a very general algorithm for doing this selection in all possible situations. Note that in practical cases (where all the signals that can be rendered can be described by a small number of values of a small number of categories) the algorithm will operate in a reasonably rapid and simple way. To start with, we assume that the renderer possesses a set of available signals. This set will naturally be partially determined by the renderer itself, but the set may also be affected by the configuration of the renderer (e.g., hearing-impaired mode vs. hearing mode) and the context of the indication (e.g., ring tone vs. ringback tone situations). The set may be finite or infinite. Of course, if the set is infinite, it can't be represented literally, but the renderer necessarily has a method of representing the set and its possible subsets. A finite set of available signals can be enumerated directly, or represented in some other way. Each available signal is described by the values of a set of categories. We assume that the renderer only knows the values for a finite set of categories; for all other categories, all available signals implicitly have the "universal", root value. Informally, the algorithm proceeds as follows: Load a set of "acceptable signals" with all available signals. Process the words in the values in the indication from left to right. As each additional word is considered, consider the portion of the value that has been examined, and remove from the acceptable set all signals which are inconsistent with that value, in that their value for that category is not equal to or below the indication's value (as processed so far). If after processing a word, one or more signals remain in the acceptable set, continue processing the next word. If after processing a word, no signals remain in the acceptable set, restore the previous state of the acceptable set and continue with the next value in the indication. At the end of processing, the acceptable set will contain one or more signals. Choose from among them according to some sort of priority system. More formally, an indication is processed by: initialize the acceptable set of signals with all available signals for each value in the indication (going left to right): for each word in the value (going left to right, which is down the tree of values): if there are acceptable signals which have a value of the category which is equal to or below the indication value as seen so far: delete all acceptable signals which do not have such a value, and continue processing this value else cease processing this value and continue with the next value the acceptable set will contain at least one signal. Choose from among the acceptable signals via some priority scheme. Let me work through an example. Let us suppose that the renderer implements three categories: reason reason-normal reason-call.waiting reason-forward reason-auto.callback reason-recall.hold reason-recall.transfer duration duration-normal duration-short duration-long locale locale-fm locale-al locale-al-sp.A locale-al-sp.B Let us suppose that the renderer has signals for all combinations of the leaf values of these categories, except that for historical reasons if "reason" has a non-universal value, "default" must be universal, and vice-versa; the signals (copied from the PSTN service providers) do not allow signaling a non-standard reason with a non-standard duration. So the allowed combinations of these two values are: reason-normal & duration reason-call.waiting & duration reason-forward & duration reason-auto.callback & duration reason-recall.hold & duration reason-recall.transfer & duration reason & duration-normal reason & duration-short reason & duration-long There are signals that combine each of these with "locale-fm", "locale-al-sp.A", and "locale-al-sp.B". To process the indication "reason-auto.callback:duration-short:locale-al-sp.A", the renderer first loads the acceptable signal set with all 27 of its signals, and then examines the indication word by word: - "reason" Removes no signals from the set. - "reason-auto.callback" Reduces the set to reason-auto.callback & duration & locale-fm reason-auto.callback & duration & locale-al-sp.A reason-auto.callback & duration & locale-al-sp.B - "duration" Removes no signals from the set. - "duration-short" Since no signals in the set have a value at or under this value, no change is made and the processing of this value ends. - "locale" Removes no signals from the set. - "locale-al" Reduces the set to reason-auto.callback & duration & locale-al-sp.A reason-auto.callback & duration & locale-al-sp.B - "locale-al-sp.A" Reduces the set to reason-auto.callback & duration & locale-al-sp.A The end of the indication is reached, and since only one signal remains in the set, it is rendered. Now, if the indication was less specific, "reason-auto.callback:duration-short:locale-al", at the end the acceptable set would be reason-auto.callback & duration & locale-al-sp.A reason-auto.callback & duration & locale-al-sp.B and the renderer would have to choose between these two signals in some way. Let us suppose that the renderer implemented a further category: mode mode-visual mode-audio and applied the value "mode-audio" to all of the above signals, but only added the following signals with "mode-visual": reason & duration-normal & locale & mode-visual reason & duration-short & locale & mode-visual reason & duration-long & locale & mode-visual That is, the only variation provided is in "duration". Then the indication "reason-auto.callback:duration-short:locale-al" would generate the same acceptable set as above, that is, there would be no "mode-visual" signals. The indication "mode-visual:reason-auto.callback:duration-short:locale-al" would generate the acceptable set: reason & duration-short & locale & mode-visual This is because the indication implies that matching "mode" is more important than matching "reason" and "duration". Once the selection for "mode-visual" has been done, no further selection can be done on "reason", but "duration-short" can be acted upon. In practice, for use with a hearing-impaired user, the initial set of signals would be restricted to those with "mode-visual". In this example, we have assumed that the user considers "mode-visual" and "mode-audio" to be equally acceptable. If we configured the renderer to only use "mode-visual" signals, then the indication "reason-auto.callback:duration-short:locale-al" would select only the signal reason & duration-short & locale & mode-visual In this configuration, the indication "mode-audio:reason-auto.callback:duration-short:locale-al" would also select that signal, because the value "mode-audio" cannot be acted upon within that set of available signals. It is effectively ignored. * Extensibility Let us now see how this scheme supports the various types of extensibility listed in Requirement C. - add further values to any existing category We could define an additional value such as reason-avaya.special If the renderer had any signals that had this value, they would be selected by an indicator containing "reason-avaya.special". If the renderer has no such signals, then in an indicator this value acts the same as "reason", that is, it has no effect. - add further categories that are orthogonal to existing categories We could define an additional category with values: avaya avaya-a avaya-b avaya-c If a renderer does not know of this category, all of its signals implicitly have the value "avaya". Because of this, when such a renderer processes a value of this category in an indicator, it never changes the available set. - semantically subdivide the meaning provided by any existing indication We could define subvalues of existing values, such as: state state-waiting state-waiting-avaya.standard state-waiting-avaya.vip If the renderer has two signals that differ only in the values "state-waiting-avaya.standard" and "state-waiting-avaya.vip", any indicator that does not know of this subdivision will never separate the two signals; they will both remain in the acceptable set or both be excluded from it. So the renderer needs a policy for choosing one over the other -- In this case, clearly "state-waiting-avaya.standard" is to be preferred. However, if the indicator gives one of the two subvalues, the renderer will select the appropriate signal. If the indicator gives one of the two subvalues but the renderer only knows of "state-waiting", the "avaya.standard" or "avaya.vip" part of the value will never affect the acceptable set (since to select based on it would make the acceptable set empty). Processing of "state-waiting-avaya.standard" would have the same effect as "state-waiting". - add further "value spaces" of indications whose semantics are not related to existing indications, and thus, whose categories differ from and do not interact with existing categories We can define completely independent spaces of signals by defining new categories to describe the new space, giving signals in one space the universal value for categories describing the other space. For example, we can define auto auto-make auto-make-volvo auto-make-toyota color color-red color-green If we have signals with the values auto-make-volvo & color-red auto-make-volvo & color-green auto-make-toyota & color-red auto-make-toyota & color-green and add them to the set of "mode-visual" signals given above, we get: reason & duration-normal & locale & mode-visual & auto & color reason & duration-short & locale & mode-visual & auto & color reason & duration-long & locale & mode-visual & auto & color reason & duration & locale & mode & auto-make-volvo & color-red reason & duration & locale & mode & auto-make-volvo & color-green reason & duration & locale & mode & auto-make-toyota & color-red reason & duration & locale & mode & auto-make-toyota & color-green This set is a combination of chalk and cheese. But the first non-universal value in the indicator will select signals of one type or the other. For instance, "auto-make" will select reason & duration & locale & mode & auto-make-volvo & color-red reason & duration & locale & mode & auto-make-volvo & color-green reason & duration & locale & mode & auto-make-toyota & color-red reason & duration & locale & mode & auto-make-toyota & color-green and "duration-normal" will select reason & duration-normal & locale & mode-visual & auto & color Dale From pkyzivat@cisco.com Tue Jun 15 11:20:20 2010 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 AE6A13A6837 for ; Tue, 15 Jun 2010 11:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.167 X-Spam-Level: X-Spam-Status: No, score=-11.167 tagged_above=-999 required=5 tests=[AWL=1.432, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raNndW3noi+F for ; Tue, 15 Jun 2010 11:20:13 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4CB5A3A6909 for ; Tue, 15 Jun 2010 11:20:11 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANdgF0xAZnwM/2dsb2JhbACecnGmcpozglmCQQQ X-IronPort-AV: E=Sophos;i="4.53,421,1272844800"; d="scan'208";a="121868288" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2010 18:15:45 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5FIFjId007080; Tue, 15 Jun 2010 18:15:45 GMT Message-ID: <4C17C351.7020405@cisco.com> Date: Tue, 15 Jun 2010 14:15:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "WORLEY, Dale R (Dale)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 15 Jun 2010 18:20:20 -0000 Very interesting! Without getting into syntax specifics, I think I like this - it provides a much cleaner conceptual framework. The idea of the specifier providing a priority seems to resolve some loose ends. Thanks, Paul WORLEY, Dale R (Dale) wrote: > [As I am the chair-elect for this topic, I now have to identify that I > am proposing this as an individual contributor-elect.] > > This is a conceptual proposal for for specifying Alert-Info URNs. The > problem that I am attacking is extensibility -- because the practical > application of the Alert-Info URNs will be as successors of the > ring tone and ringback tone implementations of innumerable existing > telephone systems, we expect the uses of Alert-Info URNs to be subject > to much extension. The primary problem is to provide a framework > which allows such extensions to be implemented without damaging > interoperability between systems whose Alert-Info usage has not been > coordinated a priori. A secondary problem is to ensure that the > framework can be implemented efficiently in practical situations. > > The basis of this proposal has been stolen from previous contributors > to the Alert-Info work. > > Since this is a conceptual proposal, I am not particular about the > syntax to be used -- the syntax shown here is just to illustrate the > concepts. What I am proposing is a system of semantics; many variant > syntaxes can be used to implement it with differing tradeoffs. > > * Terminology > > We say that a "specifier" sends an "indication" (a URN in an > Alert-Info header) to a "renderer" which then "renders" a "signal" > based on the indication to a human user. A "category" is a > characteristic whose "values" can be used to classify indications. > > * Requirements and non-requirements > > Requirement A: Indications must be able to represent a wide variety > of signals, which have many largely-orthogonal characteristics. (See > draft-liess-dispatch-alert-info-urns-00 section section 2 for a > partial list, and Paul Kyzivat's message for another partial list.) > > Requirement B: Indications include subsets which have distinctly > different semantics, that is, they form disjoint "value spaces". For > example, some indications should describe the semantics of the > signaling situation whereas others should describe the audio > characteristics of the signal. This implies that there is no single > set of categories that can be used as independent coordinates of the > value-space of indications. > > Requirement C: The set of indications must be able to support > extensibility by a wide variety of organizations that are not > coordinated with each other. Extensions must be able to: > > - add further values to any existing category > > - add further categories that are orthogonal to existing categories > > - semantically subdivide the meaning provided by any existing > indication > > - add further "value spaces" of indications whose semantics are not > related to existing indications, and thus, whose categories differ > from and do not interact with existing categories > > Requirement D: An indication is transmitted from a specifier to a > renderer, which must base its rendering decision only on the > indication. In particular, there is no multi-message negotiation > process or carrying of context from one indication to the next. > > Requirement E: The renderer may be customized in ways that limit the > set of signals that it can render, or it may be provided with a set of > signals that have uncommon semantics. (The canonical example is a UA > for the hearing-impaired.) (By Requirement D, the renderer has no way > of transmitting this fact to the specifier.) > > Requirement F: If the specifier and the renderer have designs that > are properly coordinated, the indications must be able to reliably > carry all extensions that are supported in the coordinated designs. > > Requirement G: In any situation, the renderer must be able to perform > close to the best possible rendering that it could do even the > specifier had specific knowledge of the renderer's capabilities. > > Non-Requirement H: In any situation other than that of Requirement F, > we do not require the render to perform the best possible rendering. > > * Categories, values, and indicators > > There are a theoretically infinite number of categories. Each > category is named by a word, such as: > > reason > priority > source > duration > > The values of each category conceptually form a tree. The root of the > tree is the universal, or most general, value. It is denoted by the > the category name, and represents the universe of all possibilities. > Each further subdivision of a value is specified by adding a hyphen > and another word. Thus, within the category "state" we have values: > > state > state-unknown > state-waiting > state-on.call > state-away > > (Here we pretend '.' is a letter.) > > The first of these values specifies no specific information. The > following values specify subdivisions of the semantic space. The > value "state-waiting" can be further subdivided based on the > importance of the call being waited upon: > > state-waiting-standard > state-waiting-vip > > An indication is assembled by providing a sequence of values (which > implicitly specify their categories), separated by colons, in order of > importance. That is, the first value is the one that should be > rendered as accurately as possible; within that constraint, the second > value should be rendered as accurately as possible; etc. > > For example, we can assemble the following indications: > > an internal, priority call > source-internal:priority-high > > priority call waiting > reason-call.waiting:priority-high > > short Albanian auto-callback > reason-auto.callback:duration-short:locale-al > > (The specific examples are taken from > draft-liess-dispatch-alert-info-urns-00 section 4.5, the specific > categories and values are adapted from Paul Kyzivat's message.) > > All of these indications are easily extensible. For instance, if > Albania has two service providers with different signal tones, we > could specialize the last indication into: > > short Albanian auto-callback, service provider A > reason-auto.callback:duration-short:locale-al-sp.A > > short Albanian auto-callback, service provider B > reason-auto.callback:duration-short:locale-al-sp.B > > Due to the rule that the earlier values in an indicator have more > influence than latter values, there is a subtle difference between: > > source-internal:priority-high > priority-high:source-internal > > in regard to which aspect of the indication it is more important to > render. > > * Selecting the signal based on an indication > > Having defined a universe of indications with infinite extensibility, > we now need to show that a practical device can interpret indications > to select from a limited set of signals. To do this, I will describe > a very general algorithm for doing this selection in all possible > situations. Note that in practical cases (where all the signals that > can be rendered can be described by a small number of values of a > small number of categories) the algorithm will operate in a reasonably > rapid and simple way. > > To start with, we assume that the renderer possesses a set of > available signals. This set will naturally be partially determined by > the renderer itself, but the set may also be affected by the > configuration of the renderer (e.g., hearing-impaired mode vs. hearing > mode) and the context of the indication (e.g., ring tone vs. ringback > tone situations). The set may be finite or infinite. Of course, if > the set is infinite, it can't be represented literally, but the > renderer necessarily has a method of representing the set and its > possible subsets. A finite set of available signals can be enumerated > directly, or represented in some other way. > > Each available signal is described by the values of a set of > categories. We assume that the renderer only knows the values for a > finite set of categories; for all other categories, all available > signals implicitly have the "universal", root value. > > Informally, the algorithm proceeds as follows: > > Load a set of "acceptable signals" with all available signals. > > Process the words in the values in the indication from left to right. > As each additional word is considered, consider the portion of the > value that has been examined, and remove from the acceptable set all > signals which are inconsistent with that value, in that their value > for that category is not equal to or below the indication's value (as > processed so far). > > If after processing a word, one or more signals remain in the > acceptable set, continue processing the next word. > > If after processing a word, no signals remain in the > acceptable set, restore the previous state of the acceptable > set and continue with the next value in the indication. > > At the end of processing, the acceptable set will contain one or more > signals. Choose from among them according to some sort of priority > system. > > More formally, an indication is processed by: > > initialize the acceptable set of signals with all available signals > > for each value in the indication (going left to right): > > for each word in the value (going left to right, which is down > the tree of values): > > if there are acceptable signals which have a value of the > category which is equal to or below the indication value as > seen so far: > > delete all acceptable signals which do not have such a > value, and continue processing this value > > else > > cease processing this value and continue with the next > value > > the acceptable set will contain at least one signal. Choose from > among the acceptable signals via some priority scheme. > > Let me work through an example. > > Let us suppose that the renderer implements three categories: > > reason > reason-normal > reason-call.waiting > reason-forward > reason-auto.callback > reason-recall.hold > reason-recall.transfer > > duration > duration-normal > duration-short > duration-long > > locale > locale-fm > locale-al > locale-al-sp.A > locale-al-sp.B > > Let us suppose that the renderer has signals for all combinations of > the leaf values of these categories, except that for historical > reasons if "reason" has a non-universal value, "default" must be > universal, and vice-versa; the signals (copied from the PSTN service > providers) do not allow signaling a non-standard reason with a > non-standard duration. So the allowed combinations of these two > values are: > > reason-normal & duration > reason-call.waiting & duration > reason-forward & duration > reason-auto.callback & duration > reason-recall.hold & duration > reason-recall.transfer & duration > reason & duration-normal > reason & duration-short > reason & duration-long > > There are signals that combine each of these with "locale-fm", > "locale-al-sp.A", and "locale-al-sp.B". > > To process the indication > "reason-auto.callback:duration-short:locale-al-sp.A", the renderer > first loads the acceptable signal set with all 27 of its signals, and > then examines the indication word by word: > > - "reason" > > Removes no signals from the set. > > - "reason-auto.callback" > > Reduces the set to > > reason-auto.callback & duration & locale-fm > reason-auto.callback & duration & locale-al-sp.A > reason-auto.callback & duration & locale-al-sp.B > > - "duration" > > Removes no signals from the set. > > - "duration-short" > > Since no signals in the set have a value at or under this value, no > change is made and the processing of this value ends. > > - "locale" > > Removes no signals from the set. > > - "locale-al" > > Reduces the set to > > reason-auto.callback & duration & locale-al-sp.A > reason-auto.callback & duration & locale-al-sp.B > > - "locale-al-sp.A" > > Reduces the set to > > reason-auto.callback & duration & locale-al-sp.A > > The end of the indication is reached, and since only one signal remains > in the set, it is rendered. > > Now, if the indication was less specific, > "reason-auto.callback:duration-short:locale-al", at the end the > acceptable set would be > > reason-auto.callback & duration & locale-al-sp.A > reason-auto.callback & duration & locale-al-sp.B > > and the renderer would have to choose between these two signals in > some way. > > Let us suppose that the renderer implemented a further category: > > mode > mode-visual > mode-audio > > and applied the value "mode-audio" to all of the above signals, but > only added the following signals with "mode-visual": > > reason & duration-normal & locale & mode-visual > reason & duration-short & locale & mode-visual > reason & duration-long & locale & mode-visual > > That is, the only variation provided is in "duration". > > Then the indication "reason-auto.callback:duration-short:locale-al" > would generate the same acceptable set as above, that is, there would > be no "mode-visual" signals. The indication > "mode-visual:reason-auto.callback:duration-short:locale-al" would > generate the acceptable set: > > reason & duration-short & locale & mode-visual > > This is because the indication implies that matching "mode" is more > important than matching "reason" and "duration". Once the selection > for "mode-visual" has been done, no further selection can be done on > "reason", but "duration-short" can be acted upon. > > In practice, for use with a hearing-impaired user, the initial set of > signals would be restricted to those with "mode-visual". In this > example, we have assumed that the user considers "mode-visual" and > "mode-audio" to be equally acceptable. > > If we configured the renderer to only use "mode-visual" signals, then > the indication "reason-auto.callback:duration-short:locale-al" would > select only the signal > > reason & duration-short & locale & mode-visual > > In this configuration, the indication > "mode-audio:reason-auto.callback:duration-short:locale-al" would also > select that signal, because the value "mode-audio" cannot be acted > upon within that set of available signals. It is effectively ignored. > > * Extensibility > > Let us now see how this scheme supports the various types of > extensibility listed in Requirement C. > > - add further values to any existing category > > We could define an additional value such as > > reason-avaya.special > > If the renderer had any signals that had this value, they would be > selected by an indicator containing "reason-avaya.special". If the > renderer has no such signals, then in an indicator this value acts the > same as "reason", that is, it has no effect. > > - add further categories that are orthogonal to existing categories > > We could define an additional category with values: > > avaya > avaya-a > avaya-b > avaya-c > > If a renderer does not know of this category, all of its signals > implicitly have the value "avaya". Because of this, when such a > renderer processes a value of this category in an indicator, it never > changes the available set. > > - semantically subdivide the meaning provided by any existing > indication > > We could define subvalues of existing values, such as: > > state > state-waiting > state-waiting-avaya.standard > state-waiting-avaya.vip > > If the renderer has two signals that differ only in the values > "state-waiting-avaya.standard" and "state-waiting-avaya.vip", any > indicator that does not know of this subdivision will never separate > the two signals; they will both remain in the acceptable set or both > be excluded from it. So the renderer needs a policy for choosing one > over the other -- In this case, clearly "state-waiting-avaya.standard" > is to be preferred. > > However, if the indicator gives one of the two subvalues, the renderer > will select the appropriate signal. > > If the indicator gives one of the two subvalues but the renderer only > knows of "state-waiting", the "avaya.standard" or "avaya.vip" part of > the value will never affect the acceptable set (since to select based > on it would make the acceptable set empty). Processing of > "state-waiting-avaya.standard" would have the same effect as > "state-waiting". > > - add further "value spaces" of indications whose semantics are not > related to existing indications, and thus, whose categories differ > from and do not interact with existing categories > > We can define completely independent spaces of signals by defining new > categories to describe the new space, giving signals in one space the > universal value for categories describing the other space. > > For example, we can define > > auto > auto-make > auto-make-volvo > auto-make-toyota > color > color-red > color-green > > If we have signals with the values > > auto-make-volvo & color-red > auto-make-volvo & color-green > auto-make-toyota & color-red > auto-make-toyota & color-green > > and add them to the set of "mode-visual" signals given above, we get: > > reason & duration-normal & locale & mode-visual & auto & color > reason & duration-short & locale & mode-visual & auto & color > reason & duration-long & locale & mode-visual & auto & color > reason & duration & locale & mode & auto-make-volvo & color-red > reason & duration & locale & mode & auto-make-volvo & color-green > reason & duration & locale & mode & auto-make-toyota & color-red > reason & duration & locale & mode & auto-make-toyota & color-green > > This set is a combination of chalk and cheese. But the first > non-universal value in the indicator will select signals of one type > or the other. For instance, "auto-make" will select > > reason & duration & locale & mode & auto-make-volvo & color-red > reason & duration & locale & mode & auto-make-volvo & color-green > reason & duration & locale & mode & auto-make-toyota & color-red > reason & duration & locale & mode & auto-make-toyota & color-green > > and "duration-normal" will select > > reason & duration-normal & locale & mode-visual & auto & color > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From peter.musgrave@magorcorp.com Tue Jun 15 12:38:59 2010 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 81E5B3A6927 for ; Tue, 15 Jun 2010 12:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlZeDDhoVpS9 for ; Tue, 15 Jun 2010 12:38:57 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 978203A68DA for ; Tue, 15 Jun 2010 12:38:48 -0700 (PDT) Received: by qyk8 with SMTP id 8so856679qyk.31 for ; Tue, 15 Jun 2010 12:38:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.8.80 with SMTP id g16mr3359420qag.274.1276630727893; Tue, 15 Jun 2010 12:38:47 -0700 (PDT) Received: by 10.229.217.16 with HTTP; Tue, 15 Jun 2010 12:38:47 -0700 (PDT) In-Reply-To: References: <4C06A36B.3090103@acm.org> Date: Tue, 15 Jun 2010 15:38:47 -0400 Message-ID: From: Peter Musgrave To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list Subject: Re: [dispatch] (VIPR) - VAP in or out? 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, 15 Jun 2010 19:38:59 -0000 Since the charter is just pointing to these as starting points I vote to include VAP. I see it as a reasonable starting point. Peter Musgrave On Tue, Jun 15, 2010 at 1:23 PM, Cullen Jennings wrote: > > On Jun 2, 2010, at 12:31 PM, Marc Petit-Huguenin wrote: > >>> >>> The problem statement and some possible starting points for solutions a= re further desired in the following internet drafts which shall form the ba= ses of the WG documents: >>> draft-rosenberg-dispatch-vipr-overview >>> draft-rosenberg-dispatch-vipr-reload-usage >>> draft-rosenberg-dispatch-vipr-pvp >>> draft-rosenberg-dispatch-vipr-sip-antispam >> >> VAP is not listed here. =A0Is it an oversight or is it because the WG wi= ll work >> only on interoperability between ViPR servers? > > I could go either way on VAP. On one hand, the minimal thing we need to s= tandardize to have interoperability between domain is just the above stuff = without VAP. On the other hand, VAP is a very simple way to modularize what= is happening inside a domain. VAP allows information about PSTN call to be= given to the server doing the VIPR stuff and allows the VIPR server to tel= l routing engines and PBX inside the domain about new routes. > > I'd be interested in hearing what other thing. It's easy to add something= like VAP to the charter. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From Even.roni@huawei.com Tue Jun 15 15:25:40 2010 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 299183A697A for ; Tue, 15 Jun 2010 15:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z4EPLDsF1yz for ; Tue, 15 Jun 2010 15:25:39 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0A4333A68DF for ; Tue, 15 Jun 2010 15:25:39 -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 <0L4200F44UAUGL@szxga04-in.huawei.com> for dispatch@ietf.org; Wed, 16 Jun 2010 06:25:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L42002JMUAU5Q@szxga04-in.huawei.com> for dispatch@ietf.org; Wed, 16 Jun 2010 06:25:42 +0800 (CST) Received: from windows8d787f9 ([109.67.36.119]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L42002XEUAON7@szxml02-in.huawei.com>; Wed, 16 Jun 2010 06:25:42 +0800 (CST) Date: Wed, 16 Jun 2010 01:23:18 +0300 From: Roni Even In-reply-to: To: 'Cullen Jennings' , 'DISPATCH list' Message-id: <018901cb0cd9$5ebc5af0$1c3510d0$%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: AcsBqzwgd0aRgVLbTRuXJn4D04wnPALLaH1w References: Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTN Reachability (VIPR) 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, 15 Jun 2010 22:25:40 -0000 Hi Cullen, I think that other standard body should be consulted like ITU. The reason is that I see that one assumption is to use the PSTN numbering plan using also the caller id. My experience is that this is not information that can be reliable when going between PSTN service providers and it gets worse on international calls. Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Tuesday, June 01, 2010 7:55 PM > To: DISPATCH list > Subject: [dispatch] Charter Proposal: Verification Involving PSTN > Reachability (VIPR) > > > I've been talking to a lot of people about the VIPR drafts - here is a > first cut of a proposal for a WG that could do this. I'm sure the > charter proposal needs a bunch of work but I wanted to get the > discussion rolling on the list. > > Thanks, Cullen > > (PS - this is sent in my individual contributor role. Take all my posts > about VIPR to be in my individual role not my co-chair role) > > ------------------------------------------------------- > > ViPR Charter Proposal (Version 0) > > WG Name: Verification Involving PSTN Reachability (VIPR) > > There are two globally deployed address spaces for communications that > more than a billion people use on a daily basis. They are phone numbers > and DNS rooted address such as web servers and email addresses. The > federation design of SIP is primarily designed for email style > addresses yet a large percentage of SIP deployments primarily use phone > numbers for identifying users. The goal of this working group is to > allows people to use SIP to federate over the the internet while still > using phone numbers to identify the person they wish to communicate > with. > > The VIPR WG will address this problem by developing a peer to peer > based approach to finding SIP domains that claim to be responsible for > a given phone number and the WG will design validation protocols to > ensure a reasonable likelihood that a given domain actually is > responsible for the phone number. One initial validation protocol will > be based on a domain being able to prove it received a particular phone > call over the PSTN based on both sides knowing the start and stop times > of that call. Other validation schemes, such as examining fingerprints > or watermarking of PSTN media, to show that a domain received a > particular PSTN phone call may be considered by the working group. To > help mitigate SPAM over SIP issues, the WG will define an token based > authorization scheme so that domain using SIP to federate can choose to > check that incoming SIP calls are from a domain that successfully > validated a phone number. > > The problem statement and some possible starting points for solutions > are further desired in the following internet drafts which shall form > the bases of the WG documents: > draft-rosenberg-dispatch-vipr-overview > draft-rosenberg-dispatch-vipr-reload-usage > draft-rosenberg-dispatch-vipr-pvp > draft-rosenberg-dispatch-vipr-sip-antispam > > The working group will carefully coordinate with the security area, O&M > area, as well as the appropriate RAI WG including sipcore and p2psip. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From petithug@acm.org Tue Jun 15 15:28:42 2010 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 6223F3A68DF for ; Tue, 15 Jun 2010 15:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.019 X-Spam-Level: X-Spam-Status: No, score=-99.019 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 7bJnE631tX5H for ; Tue, 15 Jun 2010 15:28:41 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 54A5F3A69A0 for ; Tue, 15 Jun 2010 15:28:41 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id B28626C98478; Tue, 15 Jun 2010 22:28:45 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 3AB006C98472; Tue, 15 Jun 2010 22:28:45 +0000 (UTC) Message-ID: <4C17FE9C.9070902@acm.org> Date: Tue, 15 Jun 2010 15:28:44 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Iceowl/1.0b1 Icedove/3.0.4 MIME-Version: 1.0 To: Cullen Jennings References: <4C06A36B.3090103@acm.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] (VIPR) - VAP in or out? 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, 15 Jun 2010 22:28:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2010 10:23 AM, Cullen Jennings wrote: > > On Jun 2, 2010, at 12:31 PM, Marc Petit-Huguenin wrote: > >>> >>> The problem statement and some possible starting points for solutions are further desired in the following internet drafts which shall form the bases of the WG documents: >>> draft-rosenberg-dispatch-vipr-overview >>> draft-rosenberg-dispatch-vipr-reload-usage >>> draft-rosenberg-dispatch-vipr-pvp >>> draft-rosenberg-dispatch-vipr-sip-antispam >> >> VAP is not listed here. Is it an oversight or is it because the WG will work >> only on interoperability between ViPR servers? > > I could go either way on VAP. On one hand, the minimal thing we need to standardize to have interoperability between domain is just the above stuff without VAP. On the other hand, VAP is a very simple way to modularize what is happening inside a domain. VAP allows information about PSTN call to be given to the server doing the VIPR stuff and allows the VIPR server to tell routing engines and PBX inside the domain about new routes. > > I'd be interested in hearing what other thing. It's easy to add something like VAP to the charter. > I do not plan to implement VAP and so will not be able to contribute on this protocol if the WG choose to work on it. So for what I am concerned, VAP does not need to be in the charter, and I think that resources will be better spent working of stuff that directly affects interoperability (and with SIP in the equation there will be no shortage of interop issue). This said, the VAP I-D is a mandatory reading to understand the behavior of a ViPR server, so there will be at least a need to split the VAP protocol from the ViPR server behavior. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwX/poACgkQ9RoMZyVa61f8yACgmbFovAvocpMTKoZyznHanYmX JPIAn1H8eGxHHP7PV5AEkwCaiZh1sfab =quJ4 -----END PGP SIGNATURE----- From Even.roni@huawei.com Tue Jun 15 23:25:41 2010 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 534593A6855 for ; Tue, 15 Jun 2010 23:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP2TmUwf0MBH for ; Tue, 15 Jun 2010 23:25:40 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BAD623A685B for ; Tue, 15 Jun 2010 23:25:35 -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 <0L4300L0YGIDQ1@szxga04-in.huawei.com> for dispatch@ietf.org; Wed, 16 Jun 2010 14:25:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4300M7JGID2O@szxga04-in.huawei.com> for dispatch@ietf.org; Wed, 16 Jun 2010 14:25:25 +0800 (CST) Received: from windows8d787f9 ([109.67.11.221]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L430025IGHZAI@szxml01-in.huawei.com>; Wed, 16 Jun 2010 14:25:25 +0800 (CST) Date: Wed, 16 Jun 2010 09:22:52 +0300 From: Roni Even In-reply-to: To: 'Cullen Jennings' , 'DISPATCH list' Message-id: <01a601cb0d1c$61ccd3d0$25667b70$%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: AcsMr6/ka25dRpJBRX2L5fV+NH9GnQAasQwg X-CR-Hashedpuzzle: BJRf BYpM FSaz FyLS Gb25 HR/+ Iy2M KqtS NIlu OFES OFIE OeWm TETf Tqwp UROK WKpJ; 2; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAZgBsAHUAZgBmAHkAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sosha1_v1; 7; {86381568-2070-48E6-A13C-B76F3A7272B9}; ZQB2AGUAbgAuAHIAbwBuAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Wed, 16 Jun 2010 06:22:38 GMT; UgBFADoAIABbAGQAaQBzAHAAYQB0AGMAaABdACAAVgBJAFAAUgAgAC0AIABwAHIAbwBwAG8AcwBlAGQAIABjAGgAYQByAHQAZQByACAAdgBlAHIAcwBpAG8AbgAgADIAIAAtACAAUABTAFQATgA/AA== X-CR-Puzzleid: {86381568-2070-48E6-A13C-B76F3A7272B9} References: Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 16 Jun 2010 06:25:41 -0000 Hi, I read the charter and the listed drafts. I have no problem with the first two paragraph of the charter "There are two globally deployed address spaces for communications that more than a billion people use on a daily basis. They are phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users. The goal of this working group is to enable inter-domains communications over the internet, using protocol such as SIP, while still allowing people to use phone numbers to identify the person they wish to communicate with. The VIPR WG will address this problem by developing a peer to peer based approach to finding domains that claim to be responsible for a given phone number and validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number." I have a concern about using PSTN infrastructure for the reachability. My understanding so far was that SIP is trying to provide a new way for end to end communication that will replace the existing circuit switch infrastructure. This proposal says that the way to achieve end to end connectivity requires to have an end to end PSTN frastructure. The third paragraph is talking about validation using PSTN calls. I think that we can look at validation of number ownership but should say that requiring PSTN calls to do it is not the recommended approach. This will allow managing of PSTN numbers not in the scope of PSTN infrastructure. Even the PSTN network is using external protocol like SS7 to route calls using databases for achieving reachability so why not say we can use similar infrastructure that will be IP based. I can understand this as a temporary solution but not as a standard developed by the IETF. Thanks Roni Even From laura.liess.dt@googlemail.com Wed Jun 16 01:11:14 2010 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 E354F3A6AF1 for ; Wed, 16 Jun 2010 01:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bShiojcv+Ysn for ; Wed, 16 Jun 2010 01:11:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 96DD53A6971 for ; Wed, 16 Jun 2010 01:11:08 -0700 (PDT) Received: by wwc33 with SMTP id 33so273837wwc.31 for ; Wed, 16 Jun 2010 01:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X765XEOzM/BOTFzqN0NBcuppsJgA4ej25kH5U/jSCWw=; b=YZAFtEpNnxJVL9MJA5x0Ztv2hjBIDmgRAcXeTi5J1Vt/VOTEib/dJDGmFynSYv7gfO qxDfPe87NqUiFYw55USKQ5heWqXnGKayw/6vexJRw6BbXf5kPSWVaKMzIvkUgnteR9aG FKcPddPctR4eIMMrVE0XrD8kwJkTpw9qQaXRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EUs9sob9HUbz1BolI4y1543kHoluW4jxNfpetIwKwSp3zAblIv1wuxJFJqooxLS9qn UcyvvzzHadZoTZfu2y3RLJeHi1bQ+gBJE+RPD1a1wnjcB9ZlmJXFi4Xkt9+5XzVTfxXe RJrONwP+6brYnKEKZSoLH1rcJUxay2VZJhMGs= MIME-Version: 1.0 Received: by 10.216.162.80 with SMTP id x58mr314253wek.85.1276675870156; Wed, 16 Jun 2010 01:11:10 -0700 (PDT) Received: by 10.216.169.9 with HTTP; Wed, 16 Jun 2010 01:11:10 -0700 (PDT) In-Reply-To: References: <4C1224FF.5050105@ericsson.com> <4C15C46D.3010504@ericsson.com> Date: Wed, 16 Jun 2010 10:11:10 +0200 Message-ID: From: Laura Liess To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Robert Sparks , DISPATCH list Subject: Re: [dispatch] DISPATCH-78 topics - Alert URNs 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, 16 Jun 2010 08:11:14 -0000 This would be great. We need about 20 to 30 min for presentation and discussions on the draft. Weeeks ago we had ML discussions on some key issues where I think we reached a consensus, e.g. the definitions for the Alert-Info URN syntax, alert-categories and alert-indications. However, my feeling was that not everyone interested in the issue was in the ML discussion and that we need a f2f discussion. Thanks a lot Laura 2010/6/15 Cullen Jennings : > > Let Mary and I try and to reserver 30 minutes or more for Alert-Info URN.= If ALert URN is a WG by that point, it can run it as a very short WG meeti= ng and if is not a WG we can use the time to discuss how to get to being a = WG. We still need to sort out the agenda but I don't foresee a problem with= this. > > > On Jun 13, 2010, at 11:55 PM, Gonzalo Camarillo wrote: > >> Hi, >> >> if you need face-to-face time for this, go ahead talk to the DISPATCH >> chairs so that you can either get a slot within the DISPATCH session or, >> alternatively, have an ad-hoc meeting. If we managed to charter the WG >> in time, we would have a WG meeting instead. >> >> Cheers, >> >> Gonzalo >> >> On 14/06/2010 5:37 AM, WORLEY, Dale R (Dale) wrote: >>> ________________________________________ >>> From: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] >>> >>> yes, Mary's description is correct. The process is as follows. Once we >>> agreed on the charter, I requested the IESG to review it. This charter >>> will be discussed in the next IESG telechat (the coming Thursday), >>> actually. Once the IESG is happy with it, the next step will be to have >>> an IETF-wide review. After that, we will be able to charter the WG. >>> >>> In any case, as we have said a number of times, proponents of a >>> particular piece of work should not stop working on it while we charter >>> their WG. They are encouraged to continue making progress in parallel >>> with the chartering process. >>> ________________________________________ >>> >>> That is all fine, but what are the implications regarding getting a tim= e slot at Maastricht? =A0There seem to be two choices: =A0a slot within Dis= patch, or a separately scheduled Salud session. =A0What we do not want to g= et stuck with is not being able to get time in Dispatch (because a charter = has been proposed) and not being able to get a separate session (because th= e charter hasn't gone through all the approval steps), as that would preven= t any session at =A0Maastricht. >>> >>> Dale >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From peter.musgrave@magorcorp.com Wed Jun 16 04:53:16 2010 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 781923A6B2F for ; Wed, 16 Jun 2010 04:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.29 X-Spam-Level: X-Spam-Status: No, score=0.29 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyvVmqOcbetX for ; Wed, 16 Jun 2010 04:53:15 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 8C8863A689C for ; Wed, 16 Jun 2010 04:53:15 -0700 (PDT) Received: by qwe5 with SMTP id 5so6449qwe.31 for ; Wed, 16 Jun 2010 04:53:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.96.15 with SMTP id f15mr4225848qan.67.1276689197154; Wed, 16 Jun 2010 04:53:17 -0700 (PDT) Received: by 10.229.217.16 with HTTP; Wed, 16 Jun 2010 04:53:16 -0700 (PDT) In-Reply-To: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> References: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> Date: Wed, 16 Jun 2010 07:53:16 -0400 Message-ID: From: Peter Musgrave To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 16 Jun 2010 11:53:16 -0000 Hi, I think the use of PSTN reachability is central to ViPR and it's value. I agree there will be other ways of authenticating and that over time they may displace ViPR but I think PSTN reachability will be around for a long time. I think it is the lowest-common denominator and avoids things like trying to interface to databases of PSTN numbers and all the assorted standards and security issues that entails. I see this as a temporary solution in the same way that NAT traversal is a temporary solution :-) Perhaps we should make it clear in the charter that the work requires that a node using ViPR have the ability to make and receive PSTN calls (or interface to something that does)? I think general authentication without using PSTN reachability is a great idea - but I think that is a far larger and more complex issue. IIUC ViPR exists to circumvent that issue and provide a shorter term, standards-based, pragmatic solution. I think the more general problem would need a charter unto itself. Peter Musgrave On Wed, Jun 16, 2010 at 2:22 AM, Roni Even wrote: > Hi, > I read the charter and the listed drafts. I have no problem with the firs= t > two paragraph of the charter > > "There are two globally deployed address spaces for communications that m= ore > than a billion people use on a daily basis. They are phone numbers and DN= S > rooted address such as web servers and email addresses. The inter-domain > signaling design of SIP is primarily designed for email style addresses y= et > a large percentage of SIP deployments mostly use phone numbers for > identifying users. The goal of this working group is to enable inter-doma= ins > communications over the internet, using protocol such as SIP, while still > allowing people to use phone numbers to identify the person they wish to > communicate with. > > The VIPR WG will address this problem by developing a peer to peer based > approach to finding domains that claim to be responsible for a given phon= e > number and validation protocols to ensure a reasonable likelihood that a > given domain actually is responsible for the phone number." > > I have a concern about using PSTN infrastructure for the reachability. My > understanding so far was that SIP is trying to provide a new way for end = to > end communication that will replace the existing circuit switch > infrastructure. This proposal says that the way to achieve end to end > connectivity requires to have an end to end PSTN frastructure. > > The third paragraph is talking about validation using PSTN calls. I think > that we can look at validation of number ownership but should say that > requiring PSTN calls to do it is not the recommended approach. This will > allow managing of PSTN numbers not in the scope of PSTN infrastructure. E= ven > the PSTN network is using external protocol like SS7 to route calls using > databases for achieving reachability so why not say we can use similar > infrastructure that will be IP based. > > I can understand this as a temporary solution but not as a standard > developed by the IETF. > > > =A0Thanks > > Roni Even > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Wed Jun 16 05:51:50 2010 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 4E7EE3A689C for ; Wed, 16 Jun 2010 05:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.525 X-Spam-Level: X-Spam-Status: No, score=-9.525 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAu2cFlv3PDy for ; Wed, 16 Jun 2010 05:51:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3627C3A67D3 for ; Wed, 16 Jun 2010 05:51:49 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,426,1272844800"; d="scan'208";a="122147286" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2010 12:51:53 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5GCprtr023450; Wed, 16 Jun 2010 12:51:53 GMT Message-ID: <4C18C8F1.90809@cisco.com> Date: Wed, 16 Jun 2010 08:52:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Roni Even References: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> In-Reply-To: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'DISPATCH list' Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 16 Jun 2010 12:51:50 -0000 Roni Even wrote: > I have a concern about using PSTN infrastructure for the reachability. My > understanding so far was that SIP is trying to provide a new way for end to > end communication that will replace the existing circuit switch > infrastructure. This proposal says that the way to achieve end to end > connectivity requires to have an end to end PSTN frastructure. > > The third paragraph is talking about validation using PSTN calls. I think > that we can look at validation of number ownership but should say that > requiring PSTN calls to do it is not the recommended approach. This will > allow managing of PSTN numbers not in the scope of PSTN infrastructure. Even > the PSTN network is using external protocol like SS7 to route calls using > databases for achieving reachability so why not say we can use similar > infrastructure that will be IP based. > > I can understand this as a temporary solution but not as a standard > developed by the IETF. I have had similar concerns for some time - this strategy is not an "end game". BUT, at the moment there is nothing better for most phone numbers. That will probably be true for quite some time. So I think it must be *part* of the solution. It is a way to bootstrap the process. Note that this is compatible with using SIP for "PSTN" calls. Many SPs now have SIP Trunks, and calls over these can be used for ViPR validation. Eventually there should be some other mechanism that doesn't depend on PSTN calls. Maybe ViPR will motivate the deployment of Public ENUM. Or maybe there will be something else. But in any case having *something* in place should kickstart the process. Thanks, Paul From laura.liess.dt@googlemail.com Wed Jun 16 06:12:09 2010 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 CFE613A6800 for ; Wed, 16 Jun 2010 06:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=1.781, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdnBRAsCVjS7 for ; Wed, 16 Jun 2010 06:12:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5897B3A67A7 for ; Wed, 16 Jun 2010 06:12:05 -0700 (PDT) Received: by wya21 with SMTP id 21so1997198wya.31 for ; Wed, 16 Jun 2010 06:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uHF1VfNNubS20GBHGaCrR7Tdn8ZHSqz3znakKLaNvWE=; b=jnxZ3vATAbLwe2EoqENAFI4zCzKdHlFey1U7Izk7LjK16imAx7e/n3oTTseHz0IT7O ygTvIxPy5T8LsCGNz83Ni2WxvC8QYO2d4YDcFBsxDcHT0zwDkpp5ggW+4N9GQy3sJU8a vdl5Oc07b2kmskCRSGeLrT3f8dnw10/rZ+cy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LIOA9T2xuQlXY8WHYyphVf2UH07+MyOIQIjL1uRU//JOYXOA/ZlHFQzzl9IURMNkP4 AgqZiOUyVzIQyMwaSxokksluIgUxhjTHPxinIeKn8iaGXTT9TAGbBlwPcJDQ8bIrrTPD 2mAro8N89BdJAn3y5bVtKlScXiph1N2JCWoog= MIME-Version: 1.0 Received: by 10.216.85.74 with SMTP id t52mr4963926wee.99.1276693925708; Wed, 16 Jun 2010 06:12:05 -0700 (PDT) Received: by 10.216.169.9 with HTTP; Wed, 16 Jun 2010 06:12:05 -0700 (PDT) In-Reply-To: <4C17C351.7020405@cisco.com> References: <4C17C351.7020405@cisco.com> Date: Wed, 16 Jun 2010 15:12:05 +0200 Message-ID: From: Laura Liess To: Paul Kyzivat , "WORLEY, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 16 Jun 2010 13:12:10 -0000 Dale, Paul, what about trying to combine Dale's conceptual framework (which also seems to me to solve the semantic-non semantic discussion) and the syntax Paul and John and I agreed upon http://www.ietf.org/mail-archive/web/dispatch/current/msg01618.html back in April ? I think they could fit together, or do you see any issues where they don't? Laura 2010/6/15 Paul Kyzivat : > Very interesting! > > Without getting into syntax specifics, I think I like this - it provides = a > much cleaner conceptual framework. The idea of the specifier providing a > priority seems to resolve some loose ends. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > WORLEY, Dale R (Dale) wrote: >> >> [As I am the chair-elect for this topic, I now have to identify that I >> am proposing this as an individual contributor-elect.] >> >> This is a conceptual proposal for for specifying Alert-Info URNs. =A0The >> problem that I am attacking is extensibility -- because the practical >> application of the Alert-Info URNs will be as successors of the >> ring tone and ringback tone implementations of innumerable existing >> telephone systems, we expect the uses of Alert-Info URNs to be subject >> to much extension. =A0The primary problem is to provide a framework >> which allows such extensions to be implemented without damaging >> interoperability between systems whose Alert-Info usage has not been >> coordinated a priori. =A0A secondary problem is to ensure that the >> framework can be implemented efficiently in practical situations. >> >> The basis of this proposal has been stolen from previous contributors >> to the Alert-Info work. >> >> Since this is a conceptual proposal, I am not particular about the >> syntax to be used -- the syntax shown here is just to illustrate the >> concepts. =A0What I am proposing is a system of semantics; many variant >> syntaxes can be used to implement it with differing tradeoffs. >> >> * Terminology >> >> We say that a "specifier" sends an "indication" (a URN in an >> Alert-Info header) to a "renderer" which then "renders" a "signal" >> based on the indication to a human user. =A0A "category" is a >> characteristic whose "values" can be used to classify indications. >> >> * Requirements and non-requirements >> >> Requirement A: =A0Indications must be able to represent a wide variety >> of signals, which have many largely-orthogonal characteristics. =A0(See >> draft-liess-dispatch-alert-info-urns-00 section section 2 for a >> partial list, and Paul Kyzivat's message for another partial list.) >> >> Requirement B: =A0Indications include subsets which have distinctly >> different semantics, that is, they form disjoint "value spaces". =A0For >> example, some indications should describe the semantics of the >> signaling situation whereas others should describe the audio >> characteristics of the signal. =A0This implies that there is no single >> set of categories that can be used as independent coordinates of the >> value-space of indications. >> >> Requirement C: =A0The set of indications must be able to support >> extensibility by a wide variety of organizations that are not >> coordinated with each other. =A0Extensions must be able to: >> >> - add further values to any existing category >> >> - add further categories that are orthogonal to existing categories >> >> - semantically subdivide the meaning provided by any existing >> =A0indication >> >> - add further "value spaces" of indications whose semantics are not >> =A0related to existing indications, and thus, whose categories differ >> =A0from and do not interact with existing categories >> >> Requirement D: =A0An indication is transmitted from a specifier to a >> renderer, which must base its rendering decision only on the >> indication. =A0In particular, there is no multi-message negotiation >> process or carrying of context from one indication to the next. >> >> Requirement E: =A0The renderer may be customized in ways that limit the >> set of signals that it can render, or it may be provided with a set of >> signals that have uncommon semantics. =A0(The canonical example is a UA >> for the hearing-impaired.) =A0(By Requirement D, the renderer has no way >> of transmitting this fact to the specifier.) >> >> Requirement F: =A0If the specifier and the renderer have designs that >> are properly coordinated, the indications must be able to reliably >> carry all extensions that are supported in the coordinated designs. >> >> Requirement G: =A0In any situation, the renderer must be able to perform >> close to the best possible rendering that it could do even the >> specifier had specific knowledge of the renderer's capabilities. >> >> Non-Requirement H: =A0In any situation other than that of Requirement F, >> we do not require the render to perform the best possible rendering. >> >> * Categories, values, and indicators >> >> There are a theoretically infinite number of categories. =A0Each >> category is named by a word, such as: >> >> =A0 =A0reason >> =A0 =A0priority >> =A0 =A0source >> =A0 =A0duration >> >> The values of each category conceptually form a tree. =A0The root of the >> tree is the universal, or most general, value. =A0It is denoted by the >> the category name, and represents the universe of all possibilities. >> Each further subdivision of a value is specified by adding a hyphen >> and another word. =A0Thus, within the category "state" we have values: >> >> =A0 =A0state >> =A0 =A0state-unknown >> =A0 =A0state-waiting >> =A0 =A0state-on.call >> =A0 =A0state-away >> >> (Here we pretend '.' is a letter.) >> >> The first of these values specifies no specific information. =A0The >> following values specify subdivisions of the semantic space. =A0The >> value "state-waiting" can be further subdivided based on the >> importance of the call being waited upon: >> >> =A0 =A0state-waiting-standard >> =A0 =A0state-waiting-vip >> >> An indication is assembled by providing a sequence of values (which >> implicitly specify their categories), separated by colons, in order of >> importance. =A0That is, the first value is the one that should be >> rendered as accurately as possible; within that constraint, the second >> value should be rendered as accurately as possible; etc. >> >> For example, we can assemble the following indications: >> >> =A0 =A0an internal, priority call >> =A0 =A0 =A0 =A0source-internal:priority-high >> >> =A0 =A0priority call waiting >> =A0 =A0 =A0 =A0reason-call.waiting:priority-high >> >> =A0 =A0short Albanian auto-callback >> =A0 =A0 =A0 =A0reason-auto.callback:duration-short:locale-al >> >> (The specific examples are taken from >> draft-liess-dispatch-alert-info-urns-00 section 4.5, the specific >> categories and values are adapted from Paul Kyzivat's message.) >> >> All of these indications are easily extensible. =A0For instance, if >> Albania has two service providers with different signal tones, we >> could specialize the last indication into: >> >> =A0 =A0short Albanian auto-callback, service provider A >> =A0 =A0 =A0 =A0reason-auto.callback:duration-short:locale-al-sp.A >> >> =A0 =A0short Albanian auto-callback, service provider B >> =A0 =A0 =A0 =A0reason-auto.callback:duration-short:locale-al-sp.B >> >> Due to the rule that the earlier values in an indicator have more >> influence than latter values, there is a subtle difference between: >> >> =A0 =A0source-internal:priority-high >> =A0 =A0priority-high:source-internal >> >> in regard to which aspect of the indication it is more important to >> render. >> >> * Selecting the signal based on an indication >> >> Having defined a universe of indications with infinite extensibility, >> we now need to show that a practical device can interpret indications >> to select from a limited set of signals. =A0To do this, I will describe >> a very general algorithm for doing this selection in all possible >> situations. =A0Note that in practical cases (where all the signals that >> can be rendered can be described by a small number of values of a >> small number of categories) the algorithm will operate in a reasonably >> rapid and simple way. >> >> To start with, we assume that the renderer possesses a set of >> available signals. =A0This set will naturally be partially determined by >> the renderer itself, but the set may also be affected by the >> configuration of the renderer (e.g., hearing-impaired mode vs. hearing >> mode) and the context of the indication (e.g., ring tone vs. ringback >> tone situations). =A0The set may be finite or infinite. =A0Of course, if >> the set is infinite, it can't be represented literally, but the >> renderer necessarily has a method of representing the set and its >> possible subsets. =A0A finite set of available signals can be enumerated >> directly, or represented in some other way. >> >> Each available signal is described by the values of a set of >> categories. =A0We assume that the renderer only knows the values for a >> finite set of categories; for all other categories, all available >> signals implicitly have the "universal", root value. >> >> Informally, the algorithm proceeds as follows: >> >> =A0 =A0Load a set of "acceptable signals" with all available signals. >> >> =A0 =A0Process the words in the values in the indication from left to ri= ght. >> =A0 =A0As each additional word is considered, consider the portion of th= e >> =A0 =A0value that has been examined, and remove from the acceptable set = all >> =A0 =A0signals which are inconsistent with that value, in that their val= ue >> =A0 =A0for that category is not equal to or below the indication's value= (as >> =A0 =A0processed so far). >> >> =A0 =A0 =A0 =A0If after processing a word, one or more signals remain in= the >> =A0 =A0 =A0 =A0acceptable set, continue processing the next word. >> >> =A0 =A0 =A0 =A0If after processing a word, no signals remain in the >> =A0 =A0 =A0 =A0acceptable set, restore the previous state of the accepta= ble >> =A0 =A0 =A0 =A0set and continue with the next value in the indication. >> >> =A0 =A0At the end of processing, the acceptable set will contain one or = more >> =A0 =A0signals. =A0Choose from among them according to some sort of prio= rity >> =A0 =A0system. >> >> More formally, an indication is processed by: >> >> =A0 =A0 =A0initialize the acceptable set of signals with all available s= ignals >> >> =A0 =A0 =A0for each value in the indication (going left to right): >> >> =A0 =A0 =A0 =A0 =A0for each word in the value (going left to right, whic= h is down >> =A0 =A0 =A0 =A0 =A0the tree of values): >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0if there are acceptable signals which have a = value of the >> =A0 =A0 =A0 =A0 =A0 =A0 =A0category which is equal to or below the indic= ation value as >> =A0 =A0 =A0 =A0 =A0 =A0 =A0seen so far: >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0delete all acceptable signals which d= o not have such a >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value, and continue processing this v= alue >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0else >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cease processing this value and conti= nue with the next >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0value >> >> =A0 =A0 =A0the acceptable set will contain at least one signal. =A0Choos= e from >> =A0 =A0 =A0among the acceptable signals via some priority scheme. >> >> Let me work through an example. >> >> Let us suppose that the renderer implements three categories: >> >> =A0 =A0reason >> =A0 =A0 =A0 =A0reason-normal >> =A0 =A0 =A0 =A0reason-call.waiting >> =A0 =A0 =A0 =A0reason-forward >> =A0 =A0 =A0 =A0reason-auto.callback >> =A0 =A0 =A0 =A0reason-recall.hold >> =A0 =A0 =A0 =A0reason-recall.transfer >> >> =A0 =A0duration >> =A0 =A0 =A0 =A0duration-normal >> =A0 =A0 =A0 =A0duration-short >> =A0 =A0 =A0 =A0duration-long >> >> =A0 =A0locale >> =A0 =A0 =A0 =A0locale-fm >> =A0 =A0 =A0 =A0locale-al >> =A0 =A0 =A0 =A0 =A0 =A0locale-al-sp.A >> =A0 =A0 =A0 =A0 =A0 =A0locale-al-sp.B >> >> Let us suppose that the renderer has signals for all combinations of >> the leaf values of these categories, except that for historical >> reasons if "reason" has a non-universal value, "default" must be >> universal, and vice-versa; the signals (copied from the PSTN service >> providers) do not allow signaling a non-standard reason with a >> non-standard duration. =A0So the allowed combinations of these two >> values are: >> >> =A0 =A0reason-normal & duration >> =A0 =A0reason-call.waiting & duration >> =A0 =A0reason-forward & duration >> =A0 =A0reason-auto.callback & duration >> =A0 =A0reason-recall.hold & duration >> =A0 =A0reason-recall.transfer & duration >> =A0 =A0reason & duration-normal >> =A0 =A0reason & duration-short >> =A0 =A0reason & duration-long >> >> There are signals that combine each of these with "locale-fm", >> "locale-al-sp.A", and "locale-al-sp.B". >> >> To process the indication >> "reason-auto.callback:duration-short:locale-al-sp.A", the renderer >> first loads the acceptable signal set with all 27 of its signals, and >> then examines the indication word by word: >> >> - "reason" >> >> Removes no signals from the set. >> >> - "reason-auto.callback" >> >> Reduces the set to >> >> =A0 =A0reason-auto.callback & duration & locale-fm >> =A0 =A0reason-auto.callback & duration & locale-al-sp.A >> =A0 =A0reason-auto.callback & duration & locale-al-sp.B >> >> - "duration" >> >> Removes no signals from the set. >> >> - "duration-short" >> >> Since no signals in the set have a value at or under this value, no >> change is made and the processing of this value ends. >> >> - "locale" >> >> Removes no signals from the set. >> >> - "locale-al" >> >> Reduces the set to >> >> =A0 =A0reason-auto.callback & duration & locale-al-sp.A >> =A0 =A0reason-auto.callback & duration & locale-al-sp.B >> >> - "locale-al-sp.A" >> >> Reduces the set to >> >> =A0 =A0reason-auto.callback & duration & locale-al-sp.A >> >> The end of the indication is reached, and since only one signal remains >> in the set, it is rendered. >> >> Now, if the indication was less specific, >> "reason-auto.callback:duration-short:locale-al", at the end the >> acceptable set would be >> >> =A0 =A0reason-auto.callback & duration & locale-al-sp.A >> =A0 =A0reason-auto.callback & duration & locale-al-sp.B >> >> and the renderer would have to choose between these two signals in >> some way. >> >> Let us suppose that the renderer implemented a further category: >> >> =A0 =A0mode >> =A0 =A0 =A0 =A0mode-visual >> =A0 =A0 =A0 =A0mode-audio >> >> and applied the value "mode-audio" to all of the above signals, but >> only added the following signals with "mode-visual": >> >> =A0 =A0reason & duration-normal & locale & mode-visual >> =A0 =A0reason & duration-short & locale & mode-visual >> =A0 =A0reason & duration-long & locale & mode-visual >> >> That is, the only variation provided is in "duration". >> >> Then the indication "reason-auto.callback:duration-short:locale-al" >> would generate the same acceptable set as above, that is, there would >> be no "mode-visual" signals. =A0The indication >> "mode-visual:reason-auto.callback:duration-short:locale-al" would >> generate the acceptable set: >> >> =A0 =A0reason & duration-short & locale & mode-visual >> >> This is because the indication implies that matching "mode" is more >> important than matching "reason" and "duration". =A0Once the selection >> for "mode-visual" has been done, no further selection can be done on >> "reason", but "duration-short" can be acted upon. >> >> In practice, for use with a hearing-impaired user, the initial set of >> signals would be restricted to those with "mode-visual". =A0In this >> example, we have assumed that the user considers "mode-visual" and >> "mode-audio" to be equally acceptable. >> >> If we configured the renderer to only use "mode-visual" signals, then >> the indication "reason-auto.callback:duration-short:locale-al" would >> select only the signal >> >> =A0 =A0reason & duration-short & locale & mode-visual >> >> In this configuration, the indication >> "mode-audio:reason-auto.callback:duration-short:locale-al" would also >> select that signal, because the value "mode-audio" cannot be acted >> upon within that set of available signals. =A0It is effectively ignored. >> >> * Extensibility >> >> Let us now see how this scheme supports the various types of >> extensibility listed in Requirement C. >> >> - add further values to any existing category >> >> We could define an additional value such as >> >> =A0 =A0reason-avaya.special >> >> If the renderer had any signals that had this value, they would be >> selected by an indicator containing "reason-avaya.special". =A0If the >> renderer has no such signals, then in an indicator this value acts the >> same as "reason", that is, it has no effect. >> >> - add further categories that are orthogonal to existing categories >> >> We could define an additional category with values: >> >> =A0 =A0avaya >> =A0 =A0 =A0 =A0avaya-a >> =A0 =A0 =A0 =A0avaya-b >> =A0 =A0 =A0 =A0avaya-c >> >> If a renderer does not know of this category, all of its signals >> implicitly have the value "avaya". =A0Because of this, when such a >> renderer processes a value of this category in an indicator, it never >> changes the available set. >> >> - semantically subdivide the meaning provided by any existing >> =A0indication >> >> We could define subvalues of existing values, such as: >> >> =A0 =A0state >> =A0 =A0 =A0 =A0state-waiting >> =A0 =A0 =A0 =A0 =A0 =A0state-waiting-avaya.standard >> =A0 =A0 =A0 =A0 =A0 =A0state-waiting-avaya.vip >> >> If the renderer has two signals that differ only in the values >> "state-waiting-avaya.standard" and "state-waiting-avaya.vip", any >> indicator that does not know of this subdivision will never separate >> the two signals; they will both remain in the acceptable set or both >> be excluded from it. =A0So the renderer needs a policy for choosing one >> over the other -- In this case, clearly "state-waiting-avaya.standard" >> is to be preferred. >> >> However, if the indicator gives one of the two subvalues, the renderer >> will select the appropriate signal. >> >> If the indicator gives one of the two subvalues but the renderer only >> knows of "state-waiting", the "avaya.standard" or "avaya.vip" part of >> the value will never affect the acceptable set (since to select based >> on it would make the acceptable set empty). =A0Processing of >> "state-waiting-avaya.standard" would have the same effect as >> "state-waiting". >> >> - add further "value spaces" of indications whose semantics are not >> =A0related to existing indications, and thus, whose categories differ >> =A0from and do not interact with existing categories >> >> We can define completely independent spaces of signals by defining new >> categories to describe the new space, giving signals in one space the >> universal value for categories describing the other space. >> >> For example, we can define >> >> =A0 =A0auto >> =A0 =A0 =A0 =A0auto-make >> =A0 =A0 =A0 =A0 =A0 =A0auto-make-volvo >> =A0 =A0 =A0 =A0 =A0 =A0auto-make-toyota >> =A0 =A0color >> =A0 =A0 =A0 =A0color-red >> =A0 =A0 =A0 =A0color-green >> >> If we have signals with the values >> >> =A0 =A0auto-make-volvo & color-red >> =A0 =A0auto-make-volvo & color-green >> =A0 =A0auto-make-toyota & color-red >> =A0 =A0auto-make-toyota & color-green >> >> and add them to the set of "mode-visual" signals given above, we get: >> >> =A0 =A0reason & duration-normal & locale & mode-visual & auto & color >> =A0 =A0reason & duration-short & locale & mode-visual & auto & color >> =A0 =A0reason & duration-long & locale & mode-visual & auto & color >> =A0 =A0reason & duration & locale & mode & auto-make-volvo & color-red >> =A0 =A0reason & duration & locale & mode & auto-make-volvo & color-green >> =A0 =A0reason & duration & locale & mode & auto-make-toyota & color-red >> =A0 =A0reason & duration & locale & mode & auto-make-toyota & color-gree= n >> >> This set is a combination of chalk and cheese. =A0But the first >> non-universal value in the indicator will select signals of one type >> or the other. =A0For instance, "auto-make" will select >> >> =A0 =A0reason & duration & locale & mode & auto-make-volvo & color-red >> =A0 =A0reason & duration & locale & mode & auto-make-volvo & color-green >> =A0 =A0reason & duration & locale & mode & auto-make-toyota & color-red >> =A0 =A0reason & duration & locale & mode & auto-make-toyota & color-gree= n >> >> and "duration-normal" will select >> >> =A0 =A0reason & duration-normal & locale & mode-visual & auto & color >> >> Dale >> _______________________________________________ >> 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 pkyzivat@cisco.com Wed Jun 16 06:39:14 2010 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 DD9893A6A61 for ; Wed, 16 Jun 2010 06:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.241 X-Spam-Level: X-Spam-Status: No, score=-11.241 tagged_above=-999 required=5 tests=[AWL=1.358, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6td8c5TM+lV for ; Wed, 16 Jun 2010 06:39:10 -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 42F413A687E for ; Wed, 16 Jun 2010 06:39:03 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA5xGExAZnwM/2dsb2JhbACeeXGlJZoHglmCQQQ X-IronPort-AV: E=Sophos;i="4.53,426,1272844800"; d="scan'208";a="122300773" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2010 13:39:06 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5GDd6Tk013663; Wed, 16 Jun 2010 13:39:06 GMT Message-ID: <4C18D3F9.10106@cisco.com> Date: Wed, 16 Jun 2010 09:39:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <4C17C351.7020405@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 16 Jun 2010 13:39:14 -0000 Laura Liess wrote: > Dale, Paul, > > what about trying to combine Dale's conceptual framework (which also > seems to me to solve the semantic-non semantic discussion) and the > syntax Paul and John and I agreed upon > http://www.ietf.org/mail-archive/web/dispatch/current/msg01618.html > back in April ? I think they could fit together, or do you see any > issues where they don't? I was trying to avoid syntax issues for the moment, in order to focus on the essence of Dale's proposal. But if we generally like where that is going then eventually it will come back to syntax. IIUC, in what Dale has proposed the "indication" includes a prioritized list of capability-values. If we followed the syntax of the current draft, then the prioritization would probably come by considering the order of URNs in the Alert-Info header to be significant. I think that could work. It might even be possible to generalize the rule to the treatment of all sorts of URIs in the Alert-Info header, not just this particular class of URNs. The rule would be something like: - process URIs from the A-I header in order. For each: - if it is understood, and is acceptable according to local policy: - if it can be used in conjunction with already accepted URIs: - then accept this one as well - else discard it - once that is complete, if nothing has been accepted, or if some aspect of alerting as not been addressed by what has been accepted, then fill in suitable defaults. - use the accepted URIs, plus defaults, to do the alerting. The above is a higher level "meta-policy" for alerting, within which the selection and combination rules that Dale spells out can be applied. One thing that *isn't* covered by Dale, or the above, is what to do if the "renderer" disagrees with the "specifier" about the priorities. I don't (yet) have an opinion if that is a problem that needs solving. Thanks, Paul > Laura > > 2010/6/15 Paul Kyzivat : >> Very interesting! >> >> Without getting into syntax specifics, I think I like this - it provides a >> much cleaner conceptual framework. The idea of the specifier providing a >> priority seems to resolve some loose ends. >> >> Thanks, >> Paul >> >> WORLEY, Dale R (Dale) wrote: >>> [As I am the chair-elect for this topic, I now have to identify that I >>> am proposing this as an individual contributor-elect.] >>> >>> This is a conceptual proposal for for specifying Alert-Info URNs. The >>> problem that I am attacking is extensibility -- because the practical >>> application of the Alert-Info URNs will be as successors of the >>> ring tone and ringback tone implementations of innumerable existing >>> telephone systems, we expect the uses of Alert-Info URNs to be subject >>> to much extension. The primary problem is to provide a framework >>> which allows such extensions to be implemented without damaging >>> interoperability between systems whose Alert-Info usage has not been >>> coordinated a priori. A secondary problem is to ensure that the >>> framework can be implemented efficiently in practical situations. >>> >>> The basis of this proposal has been stolen from previous contributors >>> to the Alert-Info work. >>> >>> Since this is a conceptual proposal, I am not particular about the >>> syntax to be used -- the syntax shown here is just to illustrate the >>> concepts. What I am proposing is a system of semantics; many variant >>> syntaxes can be used to implement it with differing tradeoffs. >>> >>> * Terminology >>> >>> We say that a "specifier" sends an "indication" (a URN in an >>> Alert-Info header) to a "renderer" which then "renders" a "signal" >>> based on the indication to a human user. A "category" is a >>> characteristic whose "values" can be used to classify indications. >>> >>> * Requirements and non-requirements >>> >>> Requirement A: Indications must be able to represent a wide variety >>> of signals, which have many largely-orthogonal characteristics. (See >>> draft-liess-dispatch-alert-info-urns-00 section section 2 for a >>> partial list, and Paul Kyzivat's message for another partial list.) >>> >>> Requirement B: Indications include subsets which have distinctly >>> different semantics, that is, they form disjoint "value spaces". For >>> example, some indications should describe the semantics of the >>> signaling situation whereas others should describe the audio >>> characteristics of the signal. This implies that there is no single >>> set of categories that can be used as independent coordinates of the >>> value-space of indications. >>> >>> Requirement C: The set of indications must be able to support >>> extensibility by a wide variety of organizations that are not >>> coordinated with each other. Extensions must be able to: >>> >>> - add further values to any existing category >>> >>> - add further categories that are orthogonal to existing categories >>> >>> - semantically subdivide the meaning provided by any existing >>> indication >>> >>> - add further "value spaces" of indications whose semantics are not >>> related to existing indications, and thus, whose categories differ >>> from and do not interact with existing categories >>> >>> Requirement D: An indication is transmitted from a specifier to a >>> renderer, which must base its rendering decision only on the >>> indication. In particular, there is no multi-message negotiation >>> process or carrying of context from one indication to the next. >>> >>> Requirement E: The renderer may be customized in ways that limit the >>> set of signals that it can render, or it may be provided with a set of >>> signals that have uncommon semantics. (The canonical example is a UA >>> for the hearing-impaired.) (By Requirement D, the renderer has no way >>> of transmitting this fact to the specifier.) >>> >>> Requirement F: If the specifier and the renderer have designs that >>> are properly coordinated, the indications must be able to reliably >>> carry all extensions that are supported in the coordinated designs. >>> >>> Requirement G: In any situation, the renderer must be able to perform >>> close to the best possible rendering that it could do even the >>> specifier had specific knowledge of the renderer's capabilities. >>> >>> Non-Requirement H: In any situation other than that of Requirement F, >>> we do not require the render to perform the best possible rendering. >>> >>> * Categories, values, and indicators >>> >>> There are a theoretically infinite number of categories. Each >>> category is named by a word, such as: >>> >>> reason >>> priority >>> source >>> duration >>> >>> The values of each category conceptually form a tree. The root of the >>> tree is the universal, or most general, value. It is denoted by the >>> the category name, and represents the universe of all possibilities. >>> Each further subdivision of a value is specified by adding a hyphen >>> and another word. Thus, within the category "state" we have values: >>> >>> state >>> state-unknown >>> state-waiting >>> state-on.call >>> state-away >>> >>> (Here we pretend '.' is a letter.) >>> >>> The first of these values specifies no specific information. The >>> following values specify subdivisions of the semantic space. The >>> value "state-waiting" can be further subdivided based on the >>> importance of the call being waited upon: >>> >>> state-waiting-standard >>> state-waiting-vip >>> >>> An indication is assembled by providing a sequence of values (which >>> implicitly specify their categories), separated by colons, in order of >>> importance. That is, the first value is the one that should be >>> rendered as accurately as possible; within that constraint, the second >>> value should be rendered as accurately as possible; etc. >>> >>> For example, we can assemble the following indications: >>> >>> an internal, priority call >>> source-internal:priority-high >>> >>> priority call waiting >>> reason-call.waiting:priority-high >>> >>> short Albanian auto-callback >>> reason-auto.callback:duration-short:locale-al >>> >>> (The specific examples are taken from >>> draft-liess-dispatch-alert-info-urns-00 section 4.5, the specific >>> categories and values are adapted from Paul Kyzivat's message.) >>> >>> All of these indications are easily extensible. For instance, if >>> Albania has two service providers with different signal tones, we >>> could specialize the last indication into: >>> >>> short Albanian auto-callback, service provider A >>> reason-auto.callback:duration-short:locale-al-sp.A >>> >>> short Albanian auto-callback, service provider B >>> reason-auto.callback:duration-short:locale-al-sp.B >>> >>> Due to the rule that the earlier values in an indicator have more >>> influence than latter values, there is a subtle difference between: >>> >>> source-internal:priority-high >>> priority-high:source-internal >>> >>> in regard to which aspect of the indication it is more important to >>> render. >>> >>> * Selecting the signal based on an indication >>> >>> Having defined a universe of indications with infinite extensibility, >>> we now need to show that a practical device can interpret indications >>> to select from a limited set of signals. To do this, I will describe >>> a very general algorithm for doing this selection in all possible >>> situations. Note that in practical cases (where all the signals that >>> can be rendered can be described by a small number of values of a >>> small number of categories) the algorithm will operate in a reasonably >>> rapid and simple way. >>> >>> To start with, we assume that the renderer possesses a set of >>> available signals. This set will naturally be partially determined by >>> the renderer itself, but the set may also be affected by the >>> configuration of the renderer (e.g., hearing-impaired mode vs. hearing >>> mode) and the context of the indication (e.g., ring tone vs. ringback >>> tone situations). The set may be finite or infinite. Of course, if >>> the set is infinite, it can't be represented literally, but the >>> renderer necessarily has a method of representing the set and its >>> possible subsets. A finite set of available signals can be enumerated >>> directly, or represented in some other way. >>> >>> Each available signal is described by the values of a set of >>> categories. We assume that the renderer only knows the values for a >>> finite set of categories; for all other categories, all available >>> signals implicitly have the "universal", root value. >>> >>> Informally, the algorithm proceeds as follows: >>> >>> Load a set of "acceptable signals" with all available signals. >>> >>> Process the words in the values in the indication from left to right. >>> As each additional word is considered, consider the portion of the >>> value that has been examined, and remove from the acceptable set all >>> signals which are inconsistent with that value, in that their value >>> for that category is not equal to or below the indication's value (as >>> processed so far). >>> >>> If after processing a word, one or more signals remain in the >>> acceptable set, continue processing the next word. >>> >>> If after processing a word, no signals remain in the >>> acceptable set, restore the previous state of the acceptable >>> set and continue with the next value in the indication. >>> >>> At the end of processing, the acceptable set will contain one or more >>> signals. Choose from among them according to some sort of priority >>> system. >>> >>> More formally, an indication is processed by: >>> >>> initialize the acceptable set of signals with all available signals >>> >>> for each value in the indication (going left to right): >>> >>> for each word in the value (going left to right, which is down >>> the tree of values): >>> >>> if there are acceptable signals which have a value of the >>> category which is equal to or below the indication value as >>> seen so far: >>> >>> delete all acceptable signals which do not have such a >>> value, and continue processing this value >>> >>> else >>> >>> cease processing this value and continue with the next >>> value >>> >>> the acceptable set will contain at least one signal. Choose from >>> among the acceptable signals via some priority scheme. >>> >>> Let me work through an example. >>> >>> Let us suppose that the renderer implements three categories: >>> >>> reason >>> reason-normal >>> reason-call.waiting >>> reason-forward >>> reason-auto.callback >>> reason-recall.hold >>> reason-recall.transfer >>> >>> duration >>> duration-normal >>> duration-short >>> duration-long >>> >>> locale >>> locale-fm >>> locale-al >>> locale-al-sp.A >>> locale-al-sp.B >>> >>> Let us suppose that the renderer has signals for all combinations of >>> the leaf values of these categories, except that for historical >>> reasons if "reason" has a non-universal value, "default" must be >>> universal, and vice-versa; the signals (copied from the PSTN service >>> providers) do not allow signaling a non-standard reason with a >>> non-standard duration. So the allowed combinations of these two >>> values are: >>> >>> reason-normal & duration >>> reason-call.waiting & duration >>> reason-forward & duration >>> reason-auto.callback & duration >>> reason-recall.hold & duration >>> reason-recall.transfer & duration >>> reason & duration-normal >>> reason & duration-short >>> reason & duration-long >>> >>> There are signals that combine each of these with "locale-fm", >>> "locale-al-sp.A", and "locale-al-sp.B". >>> >>> To process the indication >>> "reason-auto.callback:duration-short:locale-al-sp.A", the renderer >>> first loads the acceptable signal set with all 27 of its signals, and >>> then examines the indication word by word: >>> >>> - "reason" >>> >>> Removes no signals from the set. >>> >>> - "reason-auto.callback" >>> >>> Reduces the set to >>> >>> reason-auto.callback & duration & locale-fm >>> reason-auto.callback & duration & locale-al-sp.A >>> reason-auto.callback & duration & locale-al-sp.B >>> >>> - "duration" >>> >>> Removes no signals from the set. >>> >>> - "duration-short" >>> >>> Since no signals in the set have a value at or under this value, no >>> change is made and the processing of this value ends. >>> >>> - "locale" >>> >>> Removes no signals from the set. >>> >>> - "locale-al" >>> >>> Reduces the set to >>> >>> reason-auto.callback & duration & locale-al-sp.A >>> reason-auto.callback & duration & locale-al-sp.B >>> >>> - "locale-al-sp.A" >>> >>> Reduces the set to >>> >>> reason-auto.callback & duration & locale-al-sp.A >>> >>> The end of the indication is reached, and since only one signal remains >>> in the set, it is rendered. >>> >>> Now, if the indication was less specific, >>> "reason-auto.callback:duration-short:locale-al", at the end the >>> acceptable set would be >>> >>> reason-auto.callback & duration & locale-al-sp.A >>> reason-auto.callback & duration & locale-al-sp.B >>> >>> and the renderer would have to choose between these two signals in >>> some way. >>> >>> Let us suppose that the renderer implemented a further category: >>> >>> mode >>> mode-visual >>> mode-audio >>> >>> and applied the value "mode-audio" to all of the above signals, but >>> only added the following signals with "mode-visual": >>> >>> reason & duration-normal & locale & mode-visual >>> reason & duration-short & locale & mode-visual >>> reason & duration-long & locale & mode-visual >>> >>> That is, the only variation provided is in "duration". >>> >>> Then the indication "reason-auto.callback:duration-short:locale-al" >>> would generate the same acceptable set as above, that is, there would >>> be no "mode-visual" signals. The indication >>> "mode-visual:reason-auto.callback:duration-short:locale-al" would >>> generate the acceptable set: >>> >>> reason & duration-short & locale & mode-visual >>> >>> This is because the indication implies that matching "mode" is more >>> important than matching "reason" and "duration". Once the selection >>> for "mode-visual" has been done, no further selection can be done on >>> "reason", but "duration-short" can be acted upon. >>> >>> In practice, for use with a hearing-impaired user, the initial set of >>> signals would be restricted to those with "mode-visual". In this >>> example, we have assumed that the user considers "mode-visual" and >>> "mode-audio" to be equally acceptable. >>> >>> If we configured the renderer to only use "mode-visual" signals, then >>> the indication "reason-auto.callback:duration-short:locale-al" would >>> select only the signal >>> >>> reason & duration-short & locale & mode-visual >>> >>> In this configuration, the indication >>> "mode-audio:reason-auto.callback:duration-short:locale-al" would also >>> select that signal, because the value "mode-audio" cannot be acted >>> upon within that set of available signals. It is effectively ignored. >>> >>> * Extensibility >>> >>> Let us now see how this scheme supports the various types of >>> extensibility listed in Requirement C. >>> >>> - add further values to any existing category >>> >>> We could define an additional value such as >>> >>> reason-avaya.special >>> >>> If the renderer had any signals that had this value, they would be >>> selected by an indicator containing "reason-avaya.special". If the >>> renderer has no such signals, then in an indicator this value acts the >>> same as "reason", that is, it has no effect. >>> >>> - add further categories that are orthogonal to existing categories >>> >>> We could define an additional category with values: >>> >>> avaya >>> avaya-a >>> avaya-b >>> avaya-c >>> >>> If a renderer does not know of this category, all of its signals >>> implicitly have the value "avaya". Because of this, when such a >>> renderer processes a value of this category in an indicator, it never >>> changes the available set. >>> >>> - semantically subdivide the meaning provided by any existing >>> indication >>> >>> We could define subvalues of existing values, such as: >>> >>> state >>> state-waiting >>> state-waiting-avaya.standard >>> state-waiting-avaya.vip >>> >>> If the renderer has two signals that differ only in the values >>> "state-waiting-avaya.standard" and "state-waiting-avaya.vip", any >>> indicator that does not know of this subdivision will never separate >>> the two signals; they will both remain in the acceptable set or both >>> be excluded from it. So the renderer needs a policy for choosing one >>> over the other -- In this case, clearly "state-waiting-avaya.standard" >>> is to be preferred. >>> >>> However, if the indicator gives one of the two subvalues, the renderer >>> will select the appropriate signal. >>> >>> If the indicator gives one of the two subvalues but the renderer only >>> knows of "state-waiting", the "avaya.standard" or "avaya.vip" part of >>> the value will never affect the acceptable set (since to select based >>> on it would make the acceptable set empty). Processing of >>> "state-waiting-avaya.standard" would have the same effect as >>> "state-waiting". >>> >>> - add further "value spaces" of indications whose semantics are not >>> related to existing indications, and thus, whose categories differ >>> from and do not interact with existing categories >>> >>> We can define completely independent spaces of signals by defining new >>> categories to describe the new space, giving signals in one space the >>> universal value for categories describing the other space. >>> >>> For example, we can define >>> >>> auto >>> auto-make >>> auto-make-volvo >>> auto-make-toyota >>> color >>> color-red >>> color-green >>> >>> If we have signals with the values >>> >>> auto-make-volvo & color-red >>> auto-make-volvo & color-green >>> auto-make-toyota & color-red >>> auto-make-toyota & color-green >>> >>> and add them to the set of "mode-visual" signals given above, we get: >>> >>> reason & duration-normal & locale & mode-visual & auto & color >>> reason & duration-short & locale & mode-visual & auto & color >>> reason & duration-long & locale & mode-visual & auto & color >>> reason & duration & locale & mode & auto-make-volvo & color-red >>> reason & duration & locale & mode & auto-make-volvo & color-green >>> reason & duration & locale & mode & auto-make-toyota & color-red >>> reason & duration & locale & mode & auto-make-toyota & color-green >>> >>> This set is a combination of chalk and cheese. But the first >>> non-universal value in the indicator will select signals of one type >>> or the other. For instance, "auto-make" will select >>> >>> reason & duration & locale & mode & auto-make-volvo & color-red >>> reason & duration & locale & mode & auto-make-volvo & color-green >>> reason & duration & locale & mode & auto-make-toyota & color-red >>> reason & duration & locale & mode & auto-make-toyota & color-green >>> >>> and "duration-normal" will select >>> >>> reason & duration-normal & locale & mode-visual & auto & color >>> >>> Dale >>> _______________________________________________ >>> 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 john.elwell@siemens-enterprise.com Wed Jun 16 06:44:48 2010 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 D0D5B3A6A30 for ; Wed, 16 Jun 2010 06:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nVoqpCk0bt7 for ; Wed, 16 Jun 2010 06:44:44 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id EA6E53A6828 for ; Wed, 16 Jun 2010 06:44:43 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-529981; Wed, 16 Jun 2010 15:44:48 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 098AE23F0278; Wed, 16 Jun 2010 15:44:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 16 Jun 2010 15:44:48 +0200 From: "Elwell, John" To: Cullen Jennings , Christer Holmberg Date: Wed, 16 Jun 2010 15:44:47 +0200 Thread-Topic: [dispatch] Final Charter for Session-ID? Thread-Index: AcsMlxexqhp/n5RJRR28pUkxgf7t7gAwWuqA Message-ID: References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> <1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> <4C10E050.5090102@cisco.com> <9A31589C-D364-4DB8-AA09-78A6772A8A16@cisco.com> In-Reply-To: <9A31589C-D364-4DB8-AA09-78A6772A8A16@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH list Subject: Re: [dispatch] Final Charter for Session-ID? 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, 16 Jun 2010 13:44:49 -0000 When Cullen raised the question, I was wondering whether two dialogs are re= lated if the media from the session associated with one dialog is forwarded= to the session associated with the other dialog. But then I realised that = this would not apply if you wanted to correlate two dialogs that are not se= ssion-related, e.g., two SUBSCRIBE-initiated dialogs. But on the other hand= , the term session-ID hardly seems the right term for two related SUBSCRIBE= -initiated dialogs, since there is no session involved. So the first question to be asked is whether the work should really be limi= ted to sessions, or whether it could apply to other types of dialog, or eve= n to non-dialog-forming transactions such as MESSAGE and PUBLISH when they = cross a B2BUA. Depending on the answer to this, the name and definition of = the object we are trying to describe can be selected. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 15 June 2010 15:29 > To: Christer Holmberg > Cc: DISPATCH list > Subject: Re: [dispatch] Final Charter for Session-ID? >=20 >=20 > I'm not following what you mean but it seems like this might=20 > lead to a workable definition. Can you propose something a=20 > bit more specific? >=20 >=20 > On Jun 10, 2010, at 6:57 AM, Christer Holmberg wrote: >=20 > >=20 > > Hi, > >=20 > > Isn't the linkage the fact that C is the person A addressed=20 > for this specific session? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org=20 > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 10. kes=E4kuuta 2010 15:54 > >> To: Muthu ArulMozhi Perumal (mperumal) > >> Cc: DISPATCH list > >> Subject: Re: [dispatch] Final Charter for Session-ID? > >>=20 > >>=20 > >>=20 > >> Muthu ArulMozhi Perumal (mperumal) wrote: > >>> Here is an initial attempt: > >>>=20 > >>> If there is a dialog between A and B then A and B are in=20 > a session. > >>> If there is a dialog between A and B and a dialog between B=20 > >> and C at=20 > >>> the same time then A, B and C are in a session. > >>> More generally, if two or more participants are part of a=20 > session S=20 > >>> and at the same time there is a dialog between one of the=20 > >> participants=20 > >>> of S and another participant Z who is not part of S, then S=20 > >> (union) Z=20 > >>> is a session. > >>=20 > >> The above just reiterates the problem that Cullen was raising. > >> Just because B has a dialog with A and a dialog with C does=20 > >> not mean that there is a session between A and C. A gateway=20 > >> provides a perfect example of that. > >>=20 > >> There needs to be some semantic link between the dialogs. The=20 > >> question is defining what sorts of semantic links should be=20 > >> used to share a session id. > >>=20 > >> Thanks, > >> Paul > >>=20 > >>> I think this would cover most of SBC, 3PCC an app server=20 > >> cases. People=20 > >>> can add cases like park/retrieve if they think they should be=20 > >>> considered as part of a single session. > >>>=20 > >>> Muthu > >>>=20 > >>> |-----Original Message----- > >>> |From: dispatch-bounces@ietf.org=20 > >> [mailto:dispatch-bounces@ietf.org] On > >>> Behalf > >>> |Of Cullen Jennings (fluffy) > >>> |Sent: Wednesday, June 09, 2010 8:23 PM > >>> |To: DISPATCH list > >>> |Subject: Re: [dispatch] Final Charter for Session-ID? > >>> | > >>> |I have a problem with this proposed charter. > >>> | > >>> |On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote: > >>> | > >>> |> > >>> |> The definition of a higher-layer "session" of the same=20 > >> "message-flow" > >>> is > >>> |not defined by SIP when it involves a B2BUA, and is difficult to > >>> normatively > >>> |define in practice. For the purposes of this WG charter's=20 > >> scope, two > >>> or > >>> |more dialogs of a B2BUA are correlated under any=20 > conditions where=20 > >>> |correlation might aid troubleshooting, by identifying them as=20 > >>> |belonging > >>> to > >>> |the same higher-level session. Any solution documents from this=20 > >>> |working group may expand or constrain the scope of their=20 > >> mechanism's > >>> correlation, if > >>> |the working group so decides. > >>> | > >>> |I think the above text is way too vague and impossible to=20 > >> reduce to=20 > >>> |engineering practice. If you have 10 calls going to a PSTN=20 > >> GWs that=20 > >>> |is having voice quality problems, clearly having all of=20 > >> them grouped > >>> together > >>> |is useful in debugging. Yet I doubt we want all the calls from a=20 > >>> |given > >>> PSTN > >>> |GW to have the same correlation ID. Our lack of any solid=20 > >> definition=20 > >>> |of > >>> what > >>> |it is we are trying to correlate is a strong indication to=20 > >> me that we > >>> have > >>> |not yet come to any consensus about what the problem is=20 > >> this WG would > >>> be > >>> |trying to fix. > >>> | > >>> |I would like to see a WG charted in this area but I would=20 > >> expect the > >>> IESG to > >>> |more or less laugh at a problem statement that reduced=20 > down to "uh > >>> might be > >>> |useful for debuggin". Can some people please try and=20 > propose a more > >>> concrete > >>> |definition of when two sip dialogs will be correlated? > >>> | > >>> |Cullen > >>> | > >>> |_______________________________________________ > >>> |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 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From laura.liess.dt@googlemail.com Thu Jun 17 04:21:28 2010 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 133273A6A53 for ; Thu, 17 Jun 2010 04:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+3c3p+Y40VF for ; Thu, 17 Jun 2010 04:21:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8DA493A699C for ; Thu, 17 Jun 2010 04:21:19 -0700 (PDT) Received: by wya21 with SMTP id 21so2849435wya.31 for ; Thu, 17 Jun 2010 04:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+I+4WYlqeWu4aDHNvdvuC5Aks2PxoIF4FKH/IQoIoNM=; b=cKDlplDb20yyj227U0JQz3eEPY02xPMtqEvM72Iq5YAR+5hUZyuUU6uLaG+C7dAbwf qBJPFH6gYGd3+5V9QhqUE+EcVyz7/XZX4xm3bHyuK5/vvVap+eZzdzpM3wTOnUFo9spw 3Q+5XjEqOWcUS3c8VNsoL5Xjk9t2PAeFJBEFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=AUjciiSfx9exAlS+o/WqM3GHfzelHrziS2ms/EOuuEAOUlFYw3Xq29WjqLz76UBy2e aevAJhNEJNFfV5X9cFiu1nETQCViLaZ3vlwylEnOGRYen9KdO1E6LlxaOKvrKDonZvAW VjYvi7pXnmzIkLVjN0FGh1zA/4+/4SGvR8B6M= MIME-Version: 1.0 Received: by 10.216.179.199 with SMTP id h49mr1902897wem.38.1276773317583; Thu, 17 Jun 2010 04:15:17 -0700 (PDT) Received: by 10.216.169.9 with HTTP; Thu, 17 Jun 2010 04:15:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Jun 2010 13:15:17 +0200 Message-ID: From: Laura Liess To: Paul Kyzivat , dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 17 Jun 2010 11:21:28 -0000 Dale, Please see comments inline. 2010/6/16 WORLEY, Dale R (Dale) : >> From: Paul Kyzivat > >> IIUC, in what Dale has proposed the "indication" includes a prioritized >> list of capability-values. If we followed the syntax of the current >> draft, then the prioritization would probably come by considering the >> order of URNs in the Alert-Info header to be significant. > > I would very much like to avoid having different URNs within the > Alert-Info header interact; that seems to me to be against the concept > of each URN being a distinct name. =A0(Which is why I am assuming that > the syntax allows one URN to contain multiple "values".) We had URN to contain multiple "values" in the initial proposal, see http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt, but only to some degree. We had there duration and priority in one URN, but for combining call-waiting and duration we still needed two URNs because they were different categories. For this version, we got following comment from Adam: http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html . For the next version of the draft, =A0Alan and I agreed to change to combinations of discrete tokens. So upto now we discussed two alternatives: 1) Return to URNs which contain multiple values, maybe with a modified syntax to avoid multiple URNs. Problem: We have to find a way to avoid the problem Adam pointed out to. =A02) Or we can stay with the current model of different interacting URNs within the Alert-Info header. Problem: We need to define proper combination and rendering rules. I think both could work fine if we can solve the corresponding problem. >> One thing that *isn't* covered by Dale, or the above, is what to do if >> the "renderer" disagrees with the "specifier" about the priorities. I >> don't (yet) have an opinion if that is a problem that needs solving. > > Well, strictly speaking, the renderer doesn't have to follow the > algorithm -- the normative part of the RFC will spell out what the > intention of the URN is and what the constraints on renderers are, and > we will put the algorithm in a non-normative appendix to prove that > conforming renderers can be implemented straightforwardly. > >> From: Laura Liess > >> the problem I have with this is that we have >> urn:alert:service:call-waiting already implemented and already >> specified in 3GPP. > > If that is the *only* such URN defined and implemented in 3GPP, I > expect that we can adjust the new syntax to give that one URN the > intended interpretation while still implementing the semantics we > agree upon within the whole namespace. > > Even if the syntax we decide upon is completely incompatible with this > one URN, we can explicitly define it as a special case. =A0In the most > extreme case, the RFC would define a *different* URN namespace, and we > would specify that urn:alert:service:call-waiting maps to a specific > URN in the new namespace. I would prefer this to fit in the general scheme we are going to define. > > The harder situation is if the specifier wants to indicate some > particular variant of the call-waiting signal. =A0What URN does it > provide that include the variant information while still appearing to > be "urn:alert:service:call-waiting" to 3GPP-only renderers? I hope understand your question correctly. Within 3GPP, there are no variants of the call-waiting signal. I am not aware of any being used or needed by the DT. This is probably a issue for PBXes, e.g. a short and =A0delayed call-waiting signal. (Is this what you mean by "particular variant of the call-waiting signal"?) =A0With both syntax alternatives we have up to now, we would need at least two URNs. What you look for is getting this all in only one URN, right? =A0Then we probably need a completely new syntax. Maybe it's possible. We just have to be carefull to get the problem Adam pointed out to solved. Laura > > Dale > From pkyzivat@cisco.com Thu Jun 17 06:44:31 2010 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 215EF3A6837 for ; Thu, 17 Jun 2010 06:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.01 X-Spam-Level: X-Spam-Status: No, score=-9.01 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edLYjSyElZe6 for ; Thu, 17 Jun 2010 06:44:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7B1223A68A9 for ; Thu, 17 Jun 2010 06:44:11 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAEPDGUxAZnwN/2dsb2JhbACSDIxvcaVYmjmFGgQ X-IronPort-AV: E=Sophos;i="4.53,431,1272844800"; d="scan'208";a="122570129" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2010 13:44:16 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5HDiFj0016520; Thu, 17 Jun 2010 13:44:16 GMT Message-ID: <4C1A26AE.2060401@cisco.com> Date: Thu, 17 Jun 2010 09:44:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 17 Jun 2010 13:44:31 -0000 Hmm. For some reason I have not received Dale's reply that Laura is replying to below. So I'm responding here. Thanks, Paul Laura Liess wrote: > Dale, > Please see comments inline. > > 2010/6/16 WORLEY, Dale R (Dale) : >>> From: Paul Kyzivat >>> IIUC, in what Dale has proposed the "indication" includes a prioritized >>> list of capability-values. If we followed the syntax of the current >>> draft, then the prioritization would probably come by considering the >>> order of URNs in the Alert-Info header to be significant. >> I would very much like to avoid having different URNs within the >> Alert-Info header interact; that seems to me to be against the concept >> of each URN being a distinct name. (Which is why I am assuming that >> the syntax allows one URN to contain multiple "values".) I don't see a problem there. In the general case, if there are multiple URIs then the recipient has to decide how to rationalize them into something to be done. So what is wrong with giving some guidance in that regard? Requiring all the categories to be specified in one URN has the downside that all category values need to be standardized as part of a single URN spec. Conversely, consolidating multiple URNs gives the potential to define a new category via an entirely new URN scheme. (I guess we should discuss if that is a good thing or a bad thing.) > We had URN to contain multiple "values" in the initial proposal, see > http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt, > but only to some degree. We had there duration and priority in one > URN, but for combining call-waiting and duration we still needed two > URNs because they were different categories. For this version, we got > following comment from Adam: > http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html . For > the next version of the draft, Alan and I agreed to change to > combinations of discrete tokens. > So upto now we discussed two alternatives: > 1) Return to URNs which contain multiple values, maybe with a modified > syntax to avoid multiple URNs. Problem: We have to find a way to avoid > the problem Adam pointed out to. > 2) Or we can stay with the current model of different interacting > URNs within the Alert-Info header. Problem: We need to define proper > combination and rendering rules. > > I think both could work fine if we can solve the corresponding problem. > > >>> One thing that *isn't* covered by Dale, or the above, is what to do if >>> the "renderer" disagrees with the "specifier" about the priorities. I >>> don't (yet) have an opinion if that is a problem that needs solving. >> Well, strictly speaking, the renderer doesn't have to follow the >> algorithm -- the normative part of the RFC will spell out what the >> intention of the URN is and what the constraints on renderers are, and >> we will put the algorithm in a non-normative appendix to prove that >> conforming renderers can be implemented straightforwardly. OK. You have convinced me this isn't a problem. Good! >>> From: Laura Liess >>> the problem I have with this is that we have >>> urn:alert:service:call-waiting already implemented and already >>> specified in 3GPP. >> If that is the *only* such URN defined and implemented in 3GPP, I >> expect that we can adjust the new syntax to give that one URN the >> intended interpretation while still implementing the semantics we >> agree upon within the whole namespace. >> >> Even if the syntax we decide upon is completely incompatible with this >> one URN, we can explicitly define it as a special case. In the most >> extreme case, the RFC would define a *different* URN namespace, and we >> would specify that urn:alert:service:call-waiting maps to a specific >> URN in the new namespace. > > I would prefer this to fit in the general scheme we are going to define. >> The harder situation is if the specifier wants to indicate some >> particular variant of the call-waiting signal. What URN does it >> provide that include the variant information while still appearing to >> be "urn:alert:service:call-waiting" to 3GPP-only renderers? > > I hope understand your question correctly. > Within 3GPP, there are no variants of the call-waiting signal. I am > not aware of any being used or needed by the DT. > This is probably a issue for PBXes, e.g. a short and delayed > call-waiting signal. (Is this what you mean by "particular variant of > the call-waiting signal"?) With both syntax alternatives we have up > to now, we would need at least two URNs. What you look for is getting > this all in only one URN, right? Then we probably need a completely > new syntax. Maybe it's possible. We just have to be carefull to get > the problem Adam pointed out to solved. > > Laura > >> Dale >> > From john.elwell@siemens-enterprise.com Thu Jun 17 09:24:28 2010 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 8EAFB28C0F5 for ; Thu, 17 Jun 2010 09:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlehb12r0Ifi for ; Thu, 17 Jun 2010 09:24:27 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2CD383A6AF5 for ; Thu, 17 Jun 2010 09:24:27 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-546312; Thu, 17 Jun 2010 18:24:31 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id E1D4E23F0278; Thu, 17 Jun 2010 18:24:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 17 Jun 2010 18:24:31 +0200 From: "Elwell, John" To: Cullen Jennings , DISPATCH list Date: Thu, 17 Jun 2010 18:24:30 +0200 Thread-Topic: [dispatch] VIPR - proposed charter version 2 Thread-Index: AcsMr60GvMAAZLBqTHKl5gwUKZoQPQBicrhQ 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 Subject: Re: [dispatch] VIPR - proposed charter version 2 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, 17 Jun 2010 16:24:28 -0000 "The VIPR WG will address this problem by developing a peer to peer based approach to finding domains that claim to be responsible for a given phone number..." Does it necessarily have to be a peer-to-peer based approach? The ENUM/DNS = approach is still a good approach for querying, but the issue is that with = public ENUM the database simply doesn't get populated. So the key issue is = finding a secure and attractive way of populating the database. Does the ch= arter really need to include the words "peer to peer based", or should that= be left as a matter for discussion at the solution stage? John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 15 June 2010 18:25 > To: DISPATCH list > Subject: [dispatch] VIPR - proposed charter version 2 >=20 >=20 > Thanks for all the comments on the list. Here is a revised version: >=20 > (PS. If anyone else wants to edit, this is in SVN and glad to=20 > get anyone write permission) >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > ViPR Charter Proposal (Version 2) >=20 > WG Name: Verification Involving PSTN Reachability (VIPR) >=20 > There are two globally deployed address spaces for communications that > more than a billion people use on a daily basis. They are=20 > phone numbers > and DNS rooted address such as web servers and email addresses. The > inter-domain signaling design of SIP is primarily designed for email > style addresses yet a large percentage of SIP deployments mostly use > phone numbers for identifying users. The goal of this working group is > to enable inter-domains communications over the the internet, using > protocol such as SIP, while still allowing people to use phone numbers > to identify the person they wish to communicate with. >=20 > The VIPR WG will address this problem by developing a peer to=20 > peer based > approach to finding domains that claim to be responsible for a given > phone number and validation protocols to ensure a reasonable=20 > likelihood > that a given domain actually is responsible for the phone number. In > this context, we use "responsible" to mean an administrative domain > would would be at least one of the administrative domains that a PSTN > call to this phone number would be routed to. Once the domain > responsible for the phone number is found, existing protocols such as > SIP and XMPP can be used for inter-domain communications. >=20 > Some validation protocols may be based on knowledge gathered around a > SIP call, for example, the ability to prove a call was=20 > received over the > PSTN based on start and stop times. Other validation schemes, such as > examining fingerprints or watermarking of PSTN media, to show that a > domain received a particular PSTN phone call may also be considered by > the working group. The WG will select and standardize at least one > validation scheme. >=20 > To help mitigate SPAM issues when using SIP between domains,=20 > the WG will > define a mechanisms to enable one domain to check that incoming SIP > messages from a different domain are coming from a domain that > successfully validated a phone number. The working group will=20 > define new > SIP headers and option tags to enable this. >=20 > The essential characteristic of ViPR is establishing authentication by > PSTN reachability when it is not possible to use a direct reference to > ENUM databases or other direct assertions of PSTN number > ownership. Elements such as public ENUM easily coexist with=20 > VIPR but no > direct interaction with ENUM will be required. >=20 > The problem statement and some possible starting points for solutions > are further discussed in the following internet drafts which=20 > shall form > the bases of the WG documents: >=20 > draft-rosenberg-dispatch-vipr-overview > draft-rosenberg-dispatch-vipr-reload-usage > draft-rosenberg-dispatch-vipr-pvp > draft-rosenberg-dispatch-vipr-sip-antispam >=20 > The working group will carefully coordinate with the security=20 > area, O&M > area, as well as the appropriate RAI WG including sipcore and p2psip. >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From dworley@avaya.com Thu Jun 17 12:01:20 2010 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 D02343A6B06 for ; Thu, 17 Jun 2010 12:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.222 X-Spam-Level: X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSTgYu+itVj5 for ; Thu, 17 Jun 2010 12:01:20 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 4BACA3A6887 for ; Thu, 17 Jun 2010 12:01:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,433,1272859200"; d="scan'208";a="193988280" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Jun 2010 15:01:14 -0400 X-IronPort-AV: E=Sophos;i="4.53,433,1272859200"; d="scan'208";a="484329945" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jun 2010 15:01:14 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 17 Jun 2010 15:01:13 -0400 From: "WORLEY, Dale R (Dale)" To: "Elwell, John" , Cullen Jennings , DISPATCH list Date: Thu, 17 Jun 2010 14:59:02 -0400 Thread-Topic: [dispatch] VIPR - proposed charter version 2 Thread-Index: AcsMr60GvMAAZLBqTHKl5gwUKZoQPQBicrhQAAVrmQw= 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 Subject: Re: [dispatch] VIPR - proposed charter version 2 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, 17 Jun 2010 19:01:20 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of El= well, John [john.elwell@siemens-enterprise.com] Does it necessarily have to be a peer-to-peer based approach? _______________________________________________ I'd say the essence of VIPR is that it's peer-to-peer. Or rather, that it = enables the originator to succeed without the existence of a central or rel= iable database. (A peer-to-peer structure is used as a way for terminators= to advertise their claimed addresses.) If we want to develop a database-c= entered approach, it would be disjoint from the design effort for VIPR. Dale From dworley@avaya.com Thu Jun 17 12:32:20 2010 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 9560A3A690C for ; Thu, 17 Jun 2010 12:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOGpOSQrERJJ for ; Thu, 17 Jun 2010 12:32:18 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 53EE93A6954 for ; Thu, 17 Jun 2010 12:32:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,433,1272859200"; d="scan'208";a="223609857" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jun 2010 15:32:22 -0400 X-IronPort-AV: E=Sophos;i="4.53,433,1272859200"; d="scan'208";a="473529064" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Jun 2010 15:32:22 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 17 Jun 2010 15:32:22 -0400 From: "WORLEY, Dale R (Dale)" To: Paul Kyzivat , Laura Liess Date: Thu, 17 Jun 2010 15:32:22 -0400 Thread-Topic: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs Thread-Index: AcsOI0UcV/k3eLSCS/SNsIEu1TF/9gAL8XOQ Message-ID: References: , <4C1A26AE.2060401@cisco.com> In-Reply-To: <4C1A26AE.2060401@cisco.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: "dispatch@ietf.org" Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 17 Jun 2010 19:32:20 -0000 From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] > I don't see a problem there. In the general case, if there are multiple > URIs then the recipient has to decide how to rationalize them into > something to be done. So what is wrong with giving some guidance in that > regard? We could do that, but it seems to me to be opening a can of worms, in that the guidance would be (in the general case) how to rationalize an arbitrary set of URIs. If we limit the rationalization process to the elements of a single URN of a particular namespace, the problem becomes simpler. > Requiring all the categories to be specified in one URN has the downside > that all category values need to be standardized as part of a single URN > spec. Strictly speaking, you don't have to define the entire set of standard categories in one RFC. You do need some sort of registry for them and their standardized values, but you can extend the registry with new RFCs. Of course, the vendor-specific extensions aren't cataloged anywhere. > Conversely, consolidating multiple URNs gives the potential to > define a new category via an entirely new URN scheme. (I guess we > should discuss if that is a good thing or a bad thing.) I'd vote for considering that to be a bad thing. Dale From fluffy@cisco.com Thu Jun 17 13:02:45 2010 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 492B63A69EC for ; Thu, 17 Jun 2010 13:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.359 X-Spam-Level: X-Spam-Status: No, score=-109.359 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 hIcRsqViiUlR for ; Thu, 17 Jun 2010 13:02:43 -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 72D123A6B15 for ; Thu, 17 Jun 2010 13:02:43 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAI4cGkyrR7H+/2dsb2JhbACeI1dxp26aOYJZgkEEg1I X-IronPort-AV: E=Sophos;i="4.53,433,1272844800"; d="scan'208";a="226951283" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2010 20:02:36 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5HK2YNp010592; Thu, 17 Jun 2010 20:02:35 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Thu, 17 Jun 2010 14:02:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <36131FA9-BE57-4B01-A6CC-8467BF239C40@cisco.com> References: To: John Elwell , Dale Worley X-Mailer: Apple Mail (2.1078) Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 2 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, 17 Jun 2010 20:02:45 -0000 In general I think we should make charters as specific as possible but = still broad enough to encompass the various types of solutions we want = to consider for the problem. I think that helps things get done sooner.=20= So if someone had a proposal on the table to solve this in some non peer = to peer way, it would be easier to decide if we should do it in the same = WG or something different. But we been talking about ideas for this for = 6 months now and no one has put together a proposal for some non peer to = peer approach. I've heard lots of proposal to variations of the basic = vipr scheme but they all leverages to peer to peer approach. I don't = want a charter that is so vague that it is a research project. If = someone has a specific approach that they think we should consider, then = I'd certainly want to talk about that and adjust the proposed charter = accordingly but, lacking that, I prefer a charter that makes it pretty = clear what the WG is going to go do and not an exploratory type charter.=20= As far as solving the problem with a centralized database, I think the = DRINKS/SPEERMINT folks are pretty much doing the standardization works = that would be needed for that approach. For the places that will work, = it's an easier approach than VIPR which is looking for an approach for = the places that does not make business sense.=20 Cullen PS - I know what you mean by peer to peer here but don't even get me = going about the difficulties of trying to define if something is peer to = peer or not :-)=20 On Jun 17, 2010, at 10:24 AM, Elwell, John wrote: > "The VIPR WG will address this problem by developing a peer to peer = based > approach to finding domains that claim to be responsible for a given > phone number..." > Does it necessarily have to be a peer-to-peer based approach? The = ENUM/DNS approach is still a good approach for querying, but the issue = is that with public ENUM the database simply doesn't get populated. So = the key issue is finding a secure and attractive way of populating the = database. Does the charter really need to include the words "peer to = peer based", or should that be left as a matter for discussion at the = solution stage? >=20 > John >=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > > Sent: 15 June 2010 18:25 > > To: DISPATCH list > > Subject: [dispatch] VIPR - proposed charter version 2 > > > > > > Thanks for all the comments on the list. Here is a revised version: > > > > (PS. If anyone else wants to edit, this is in SVN and glad to > > get anyone write permission) > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > ViPR Charter Proposal (Version 2) > > > > WG Name: Verification Involving PSTN Reachability (VIPR) > > > > There are two globally deployed address spaces for communications = that > > more than a billion people use on a daily basis. They are > > phone numbers > > and DNS rooted address such as web servers and email addresses. The > > inter-domain signaling design of SIP is primarily designed for email > > style addresses yet a large percentage of SIP deployments mostly use > > phone numbers for identifying users. The goal of this working group = is > > to enable inter-domains communications over the the internet, using > > protocol such as SIP, while still allowing people to use phone = numbers > > to identify the person they wish to communicate with. > > > > The VIPR WG will address this problem by developing a peer to > > peer based > > approach to finding domains that claim to be responsible for a given > > phone number and validation protocols to ensure a reasonable > > likelihood > > that a given domain actually is responsible for the phone number. In > > this context, we use "responsible" to mean an administrative domain > > would would be at least one of the administrative domains that a = PSTN > > call to this phone number would be routed to. Once the domain > > responsible for the phone number is found, existing protocols such = as > > SIP and XMPP can be used for inter-domain communications. > > > > Some validation protocols may be based on knowledge gathered around = a > > SIP call, for example, the ability to prove a call was > > received over the > > PSTN based on start and stop times. Other validation schemes, such = as > > examining fingerprints or watermarking of PSTN media, to show that a > > domain received a particular PSTN phone call may also be considered = by > > the working group. The WG will select and standardize at least one > > validation scheme. > > > > To help mitigate SPAM issues when using SIP between domains, > > the WG will > > define a mechanisms to enable one domain to check that incoming SIP > > messages from a different domain are coming from a domain that > > successfully validated a phone number. The working group will > > define new > > SIP headers and option tags to enable this. > > > > The essential characteristic of ViPR is establishing authentication = by > > PSTN reachability when it is not possible to use a direct reference = to > > ENUM databases or other direct assertions of PSTN number > > ownership. Elements such as public ENUM easily coexist with > > VIPR but no > > direct interaction with ENUM will be required. > > > > The problem statement and some possible starting points for = solutions > > are further discussed in the following internet drafts which > > shall form > > the bases of the WG documents: > > > > draft-rosenberg-dispatch-vipr-overview > > draft-rosenberg-dispatch-vipr-reload-usage > > draft-rosenberg-dispatch-vipr-pvp > > draft-rosenberg-dispatch-vipr-sip-antispam > > > > The working group will carefully coordinate with the security > > area, O&M > > area, as well as the appropriate RAI WG including sipcore and = p2psip. > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From pkyzivat@cisco.com Thu Jun 17 13:13:18 2010 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 E93143A6B10 for ; Thu, 17 Jun 2010 13:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-zkbMECSERD for ; Thu, 17 Jun 2010 13:13:13 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 55E3C3A68CB for ; Thu, 17 Jun 2010 13:13:13 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKweGkxAZnwM/2dsb2JhbACeenGnW5o5hRoE X-IronPort-AV: E=Sophos;i="4.53,433,1272844800"; d="scan'208";a="122716503" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2010 20:13:17 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5HKDHCM001468; Thu, 17 Jun 2010 20:13:17 GMT Message-ID: <4C1A81DD.9060400@cisco.com> Date: Thu, 17 Jun 2010 16:13:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "WORLEY, Dale R (Dale)" References: , <4C1A26AE.2060401@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 17 Jun 2010 20:13:18 -0000 I don't feel especially strongly one way or the other regarding the multiple URNs vs. single URN issue. Thanks, Paul WORLEY, Dale R (Dale) wrote: > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > >> I don't see a problem there. In the general case, if there are multiple >> URIs then the recipient has to decide how to rationalize them into >> something to be done. So what is wrong with giving some guidance in that >> regard? > > We could do that, but it seems to me to be opening a can of worms, in > that the guidance would be (in the general case) how to rationalize an > arbitrary set of URIs. If we limit the rationalization process to the > elements of a single URN of a particular namespace, the problem > becomes simpler. > >> Requiring all the categories to be specified in one URN has the downside >> that all category values need to be standardized as part of a single URN >> spec. > > Strictly speaking, you don't have to define the entire set of standard > categories in one RFC. You do need some sort of registry for them and > their standardized values, but you can extend the registry with new > RFCs. Of course, the vendor-specific extensions aren't cataloged > anywhere. > >> Conversely, consolidating multiple URNs gives the potential to >> define a new category via an entirely new URN scheme. (I guess we >> should discuss if that is a good thing or a bad thing.) > > I'd vote for considering that to be a bad thing. > > Dale > From fluffy@cisco.com Thu Jun 17 13:54:42 2010 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 633B63A6927 for ; Thu, 17 Jun 2010 13:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.749 X-Spam-Level: X-Spam-Status: No, score=-108.749 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, 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 m7BdjBwZ9BMg for ; Thu, 17 Jun 2010 13:54:41 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5DC563A68A3 for ; Thu, 17 Jun 2010 13:54:41 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL8oGkyrR7Hu/2dsb2JhbACee3GoA5o2glmCQQSDUg X-IronPort-AV: E=Sophos;i="4.53,434,1272844800"; d="scan'208";a="146200776" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 17 Jun 2010 20:54:46 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5HKsj8j003717; Thu, 17 Jun 2010 20:54:46 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> Date: Thu, 17 Jun 2010 14:54:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> To: Roni Even X-Mailer: Apple Mail (2.1078) Cc: 'DISPATCH list' Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 17 Jun 2010 20:54:42 -0000 I'm having a real hard time actually understand what you are objecting = too. More inline ... On Jun 16, 2010, at 12:22 AM, Roni Even wrote: > Hi, > I read the charter and the listed drafts. I have no problem with the = first > two paragraph of the charter >=20 > "There are two globally deployed address spaces for communications = that more > than a billion people use on a daily basis. They are phone numbers and = DNS > rooted address such as web servers and email addresses. The = inter-domain > signaling design of SIP is primarily designed for email style = addresses yet > a large percentage of SIP deployments mostly use phone numbers for > identifying users. The goal of this working group is to enable = inter-domains > communications over the internet, using protocol such as SIP, while = still > allowing people to use phone numbers to identify the person they wish = to > communicate with. >=20 > The VIPR WG will address this problem by developing a peer to peer = based > approach to finding domains that claim to be responsible for a given = phone > number and validation protocols to ensure a reasonable likelihood that = a > given domain actually is responsible for the phone number." >=20 > I have a concern about using PSTN infrastructure for the reachability. = My > understanding so far was that SIP is trying to provide a new way for = end to > end communication that will replace the existing circuit switch > infrastructure. This proposal says that the way to achieve end to end > connectivity requires to have an end to end PSTN frastructure. No this proposal says one of the way we can make PSTN address usable in = inter domain SIP is this. Clearly this approach would no longer be valid = when the PSTN was gone but by that point, presumably people would be = using more internet style address in SIP. Keep in mind the only thing = this work is trying to solve is mapping a PSTN address to a internet = address. When the PSTN is gone, that problem goes with it. However the = PSTN is far from gone - if I had to bet, I would guess that phone = numbers were around longer than v6 addresses (and than email style = address outlive them both). The issue is phone numbers are used by = humans which makes them very hard to transition off of while things like = v6 addresses are easier to transition off of as they are come and go = with the technologies that use them. My point being all these addresses = are around for a long time and the IETF works on standards to help = transition and interwork between them. The Telegram service was emulated = on top of other technologies long after it had been supplanted by fax - = the PSTN will be similar.=20 >=20 > The third paragraph is talking about validation using PSTN calls. I = think > that we can look at validation of number ownership but should say that > requiring PSTN calls to do it is not the recommended approach. > This will > allow managing of PSTN numbers not in the scope of PSTN = infrastructure. Even > the PSTN network is using external protocol like SS7 to route calls = using > databases for achieving reachability so why not say we can use similar > infrastructure that will be IP based. We did standardize and IP based database approach - it's called public = ENUM. However, from a practical point of view the only people that could = do the validations for ENUM are the carriers that have every business = incentive to not do it. Regulators do not have the right incentives to = regulate it into existence. VIPR on the other hand only requires = carriers to route calls. Routing calls is something they do today, it is = in their business interest so they will likely continue doing it, and = the regulation around common carriage often require them to route calls. = Both the existing regulations and economics favor that the carriers will = do what is needed to enable a solution that leverages the PSTN for = validation.=20 >=20 > I can understand this as a temporary solution but not as a standard > developed by the IETF. How temporary do you think the PSTN is? How many years? Do you think we = should not be doing standards for WG like MARTINI that only WG document = limited itself to phone numbers? Should we not have standards about SIP = / PSTN interoperability? I don't hear you objecting to any of the other = work we do hat is "temporary" in the sense it is only useful as long as = the PSTN is around. Seriously, I read this and just feel like you are grasping at straws for = something to objet to since this proposal came from Cisco.=20 >=20 >=20 > Thanks >=20 > Roni Even >=20 From fluffy@cisco.com Thu Jun 17 13:54:50 2010 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 1E3963A6B1B for ; Thu, 17 Jun 2010 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.013 X-Spam-Level: X-Spam-Status: No, score=-110.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wQ2gNqAs2t+E for ; Thu, 17 Jun 2010 13:54:49 -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 5C9303A6B15 for ; Thu, 17 Jun 2010 13:54:49 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL8oGkyrR7Hu/2dsb2JhbACee3GoA5o2hRoEg1I X-IronPort-AV: E=Sophos;i="4.53,434,1272844800"; d="scan'208";a="214011456" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 17 Jun 2010 20:54:54 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5HKsj8k003717; Thu, 17 Jun 2010 20:54:54 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Thu, 17 Jun 2010 14:54:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <71B30FB7-E517-4142-8EB3-89609ED1314A@cisco.com> References: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> To: Peter Musgrave X-Mailer: Apple Mail (2.1078) Cc: DISPATCH list , Roni Even Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 17 Jun 2010 20:54:50 -0000 On Jun 16, 2010, at 5:53 AM, Peter Musgrave wrote: > Perhaps we should make it clear in the charter that the work requires > that a node using ViPR have the ability to make and receive PSTN calls > (or interface to something that does)? That seems like a very pragmatic and good approach. I'm always a fan of = charters having truth in advertising. >=20 > I think general authentication without using PSTN reachability is a > great idea=20 Well, I think it might be more accurate to say it is "great problem". We = don't really have any ideas yet on how to solve it other than public = ENUM which is less successful than one might have hoped.=20 From Even.roni@huawei.com Thu Jun 17 15:47:37 2010 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 5BE003A6AA6 for ; Thu, 17 Jun 2010 15:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.303 X-Spam-Level: X-Spam-Status: No, score=0.303 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DCqdmvqSkIP for ; Thu, 17 Jun 2010 15:47:35 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 575123A6B30 for ; Thu, 17 Jun 2010 15:47:33 -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 <0L46001F0KN4FZ@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 18 Jun 2010 06:47:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4600MV9KN415@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 18 Jun 2010 06:47:28 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-14-20.red.bezeqint.net [79.178.14.20]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4600NGXKMQ33@szxml01-in.huawei.com>; Fri, 18 Jun 2010 06:47:28 +0800 (CST) Date: Fri, 18 Jun 2010 01:44:50 +0300 From: Roni Even In-reply-to: To: 'Cullen Jennings' Message-id: <030501cb0e6e$babab220$30301660$%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: AcsOX1fsBy6GUBzrRt2jmN/yDjOHhAABmdCA References: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> Cc: 'DISPATCH list' Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 17 Jun 2010 22:47:37 -0000 Hi Cullen, I am sorry that you feel this way about me but I do not take this personally since I am used to being blamed on lots of things. Maybe I was not clear about my view. Section 5.1 of the vipr overview provides the key properties that the solution requires and I think it is a very good summary of the requirements. I also think that dialing using E.164 numbers is better in many deployments. (My background in H.323 has led me to it and BTW I believe that any such solution can be applicable to H.323) >From this point the vipr overview suggests a solution that is hinted in the charter. The question I have is if basing the validation of ownership of the PSTN number can only be based on an actual PSTN call or does the charter allow also other ways to validate the ownership of an E.164 number and can this number be only the PSTN phone number or can it be other E.164 allocated without an attached PSTN capability. The proposed charter as I read it limits the scope to the case where the same number is used as the PSTN and SIP number. Did I understand correctly? Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Thursday, June 17, 2010 11:55 PM > To: Roni Even > Cc: 'DISPATCH list' > Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? > > > I'm having a real hard time actually understand what you are objecting > too. More inline ... > > On Jun 16, 2010, at 12:22 AM, Roni Even wrote: > > > Hi, > > I read the charter and the listed drafts. I have no problem with the > first > > two paragraph of the charter > > > > "There are two globally deployed address spaces for communications > that more > > than a billion people use on a daily basis. They are phone numbers > and DNS > > rooted address such as web servers and email addresses. The inter- > domain > > signaling design of SIP is primarily designed for email style > addresses yet > > a large percentage of SIP deployments mostly use phone numbers for > > identifying users. The goal of this working group is to enable inter- > domains > > communications over the internet, using protocol such as SIP, while > still > > allowing people to use phone numbers to identify the person they wish > to > > communicate with. > > > > The VIPR WG will address this problem by developing a peer to peer > based > > approach to finding domains that claim to be responsible for a given > phone > > number and validation protocols to ensure a reasonable likelihood > that a > > given domain actually is responsible for the phone number." > > > > I have a concern about using PSTN infrastructure for the > reachability. My > > understanding so far was that SIP is trying to provide a new way for > end to > > end communication that will replace the existing circuit switch > > infrastructure. This proposal says that the way to achieve end to end > > connectivity requires to have an end to end PSTN frastructure. > > No this proposal says one of the way we can make PSTN address usable in > inter domain SIP is this. Clearly this approach would no longer be > valid when the PSTN was gone but by that point, presumably people would > be using more internet style address in SIP. Keep in mind the only > thing this work is trying to solve is mapping a PSTN address to a > internet address. When the PSTN is gone, that problem goes with it. > However the PSTN is far from gone - if I had to bet, I would guess that > phone numbers were around longer than v6 addresses (and than email > style address outlive them both). The issue is phone numbers are used > by humans which makes them very hard to transition off of while things > like v6 addresses are easier to transition off of as they are come and > go with the technologies that use them. My point being all these > addresses are around for a long time and the IETF works on standards to > help transition and interwork between them. The Telegram service was > emulated on top of ot > her technologies long after it had been supplanted by fax - the PSTN > will be similar. > > > > > The third paragraph is talking about validation using PSTN calls. I > think > > that we can look at validation of number ownership but should say > that > > requiring PSTN calls to do it is not the recommended approach. > > This will > > allow managing of PSTN numbers not in the scope of PSTN > infrastructure. Even > > the PSTN network is using external protocol like SS7 to route calls > using > > databases for achieving reachability so why not say we can use > similar > > infrastructure that will be IP based. > > We did standardize and IP based database approach - it's called public > ENUM. However, from a practical point of view the only people that > could do the validations for ENUM are the carriers that have every > business incentive to not do it. Regulators do not have the right > incentives to regulate it into existence. VIPR on the other hand only > requires carriers to route calls. Routing calls is something they do > today, it is in their business interest so they will likely continue > doing it, and the regulation around common carriage often require them > to route calls. Both the existing regulations and economics favor that > the carriers will do what is needed to enable a solution that leverages > the PSTN for validation. > > > > > I can understand this as a temporary solution but not as a standard > > developed by the IETF. > > How temporary do you think the PSTN is? How many years? Do you think > we should not be doing standards for WG like MARTINI that only WG > document limited itself to phone numbers? Should we not have standards > about SIP / PSTN interoperability? I don't hear you objecting to any of > the other work we do hat is "temporary" in the sense it is only useful > as long as the PSTN is around. > > Seriously, I read this and just feel like you are grasping at straws > for something to objet to since this proposal came from Cisco. > > > > > > > > Thanks > > > > Roni Even > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jdrosen@jdrosen.net Thu Jun 17 18:08:49 2010 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 3A8803A6877 for ; Thu, 17 Jun 2010 18:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxl5skx8fsEH for ; Thu, 17 Jun 2010 18:08:47 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [173.205.124.201]) by core3.amsl.com (Postfix) with ESMTP id 2B3643A6874 for ; Thu, 17 Jun 2010 18:08:47 -0700 (PDT) Received: from pool-173-63-40-38.nwrknj.fios.verizon.net ([173.63.40.38] helo=[192.168.1.7]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OPQ4I-0000Uy-2g; Thu, 17 Jun 2010 21:08:26 -0400 Message-ID: <4C1AC71F.8070206@jdrosen.net> Date: Thu, 17 Jun 2010 21:08:47 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Roni Even References: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> <030501cb0e6e$babab220$30301660$%roni@huawei.com> In-Reply-To: <030501cb0e6e$babab220$30301660$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: 'DISPATCH list' Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 18 Jun 2010 01:08:49 -0000 Roni, The key requirement of the solution is that: 1. it be possible to validate the mapping of phone number to a domain which is "responsible" for that number, based on the definition Cullen has provided, and that 2. such validation be possible using only access to publicly available open interfaces to the PSTN, so that the validation can be performed by any domain wishing to participate. At the moment, the only publicly open interface to the PSTN is the ability to make a call. If you are aware of other open and publicly available interfaces by which we can perform validation, I'd love to hear about them :) Thanks, Jonathan R. Roni Even wrote: > Hi Cullen, > I am sorry that you feel this way about me but I do not take this personally > since I am used to being blamed on lots of things. > > Maybe I was not clear about my view. > Section 5.1 of the vipr overview provides the key properties that the > solution requires and I think it is a very good summary of the requirements. > I also think that dialing using E.164 numbers is better in many deployments. > (My background in H.323 has led me to it and BTW I believe that any such > solution can be applicable to H.323) > > From this point the vipr overview suggests a solution that is hinted in the > charter. > > The question I have is if basing the validation of ownership of the PSTN > number can only be based on an actual PSTN call or does the charter allow > also other ways to validate the ownership of an E.164 number and can this > number be only the PSTN phone number or can it be other E.164 allocated > without an attached PSTN capability. > > The proposed charter as I read it limits the scope to the case where the > same number is used as the PSTN and SIP number. Did I understand correctly? > > > > Roni Even > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Cullen Jennings >> Sent: Thursday, June 17, 2010 11:55 PM >> To: Roni Even >> Cc: 'DISPATCH list' >> Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? >> >> >> I'm having a real hard time actually understand what you are objecting >> too. More inline ... >> >> On Jun 16, 2010, at 12:22 AM, Roni Even wrote: >> >>> Hi, >>> I read the charter and the listed drafts. I have no problem with the >> first >>> two paragraph of the charter >>> >>> "There are two globally deployed address spaces for communications >> that more >>> than a billion people use on a daily basis. They are phone numbers >> and DNS >>> rooted address such as web servers and email addresses. The inter- >> domain >>> signaling design of SIP is primarily designed for email style >> addresses yet >>> a large percentage of SIP deployments mostly use phone numbers for >>> identifying users. The goal of this working group is to enable inter- >> domains >>> communications over the internet, using protocol such as SIP, while >> still >>> allowing people to use phone numbers to identify the person they wish >> to >>> communicate with. >>> >>> The VIPR WG will address this problem by developing a peer to peer >> based >>> approach to finding domains that claim to be responsible for a given >> phone >>> number and validation protocols to ensure a reasonable likelihood >> that a >>> given domain actually is responsible for the phone number." >>> >>> I have a concern about using PSTN infrastructure for the >> reachability. My >>> understanding so far was that SIP is trying to provide a new way for >> end to >>> end communication that will replace the existing circuit switch >>> infrastructure. This proposal says that the way to achieve end to end >>> connectivity requires to have an end to end PSTN frastructure. >> No this proposal says one of the way we can make PSTN address usable in >> inter domain SIP is this. Clearly this approach would no longer be >> valid when the PSTN was gone but by that point, presumably people would >> be using more internet style address in SIP. Keep in mind the only >> thing this work is trying to solve is mapping a PSTN address to a >> internet address. When the PSTN is gone, that problem goes with it. >> However the PSTN is far from gone - if I had to bet, I would guess that >> phone numbers were around longer than v6 addresses (and than email >> style address outlive them both). The issue is phone numbers are used >> by humans which makes them very hard to transition off of while things >> like v6 addresses are easier to transition off of as they are come and >> go with the technologies that use them. My point being all these >> addresses are around for a long time and the IETF works on standards to >> help transition and interwork between them. The Telegram service was >> emulated on top of ot >> her technologies long after it had been supplanted by fax - the PSTN >> will be similar. >> >>> The third paragraph is talking about validation using PSTN calls. I >> think >>> that we can look at validation of number ownership but should say >> that >>> requiring PSTN calls to do it is not the recommended approach. >>> This will >>> allow managing of PSTN numbers not in the scope of PSTN >> infrastructure. Even >>> the PSTN network is using external protocol like SS7 to route calls >> using >>> databases for achieving reachability so why not say we can use >> similar >>> infrastructure that will be IP based. >> We did standardize and IP based database approach - it's called public >> ENUM. However, from a practical point of view the only people that >> could do the validations for ENUM are the carriers that have every >> business incentive to not do it. Regulators do not have the right >> incentives to regulate it into existence. VIPR on the other hand only >> requires carriers to route calls. Routing calls is something they do >> today, it is in their business interest so they will likely continue >> doing it, and the regulation around common carriage often require them >> to route calls. Both the existing regulations and economics favor that >> the carriers will do what is needed to enable a solution that leverages >> the PSTN for validation. >> >>> I can understand this as a temporary solution but not as a standard >>> developed by the IETF. >> How temporary do you think the PSTN is? How many years? Do you think >> we should not be doing standards for WG like MARTINI that only WG >> document limited itself to phone numbers? Should we not have standards >> about SIP / PSTN interoperability? I don't hear you objecting to any of >> the other work we do hat is "temporary" in the sense it is only useful >> as long as the PSTN is around. >> >> Seriously, I read this and just feel like you are grasping at straws >> for something to objet to since this proposal came from Cisco. >> >> >>> >>> Thanks >>> >>> Roni Even >>> >> _______________________________________________ >> 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. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From jdrosen@jdrosen.net Thu Jun 17 18:16:38 2010 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 08A543A6874 for ; Thu, 17 Jun 2010 18:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTEDsqtwGXfW for ; Thu, 17 Jun 2010 18:16:36 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [173.205.124.201]) by core3.amsl.com (Postfix) with ESMTP id B37613A67DA for ; Thu, 17 Jun 2010 18:16:36 -0700 (PDT) Received: from pool-173-63-40-38.nwrknj.fios.verizon.net ([173.63.40.38] helo=[192.168.1.7]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OPQBt-0003Ur-Iy; Thu, 17 Jun 2010 21:16:17 -0400 Message-ID: <4C1AC8F7.9010703@jdrosen.net> Date: Thu, 17 Jun 2010 21:16:39 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 2 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, 18 Jun 2010 01:16:38 -0000 Cullen, This looks good. My major comment is that I do think we should include VAP. There are applications for VAP which are interdomain. Furthermore, even for the intra-domain case, this will be a common protocol for communicating between products made from disparate vendors. For example, PBX from vendor A talks to the ViPR server from vendor B. Other minor comments: Cullen Jennings wrote: > style addresses yet a large percentage of SIP deployments mostly use > phone numbers for identifying users. The goal of this working group is > to enable inter-domains communications over the the internet, using s/inter-domains/inter-domain > protocol such as SIP, while still allowing people to use phone numbers s/protocol/protocols > to identify the person they wish to communicate with. > > The VIPR WG will address this problem by developing a peer to peer based > approach to finding domains that claim to be responsible for a given > phone number and validation protocols to ensure a reasonable likelihood > that a given domain actually is responsible for the phone number. In > this context, we use "responsible" to mean an administrative domain > would would be at least one of the administrative domains that a PSTN double woulds. > call to this phone number would be routed to. Once the domain > responsible for the phone number is found, existing protocols such as > SIP and XMPP can be used for inter-domain communications. XMPP? really? does it support phone number addressing? > > Some validation protocols may be based on knowledge gathered around a > SIP call, for example, the ability to prove a call was received over the I think you mean PSTN call, and not a SIP call. > PSTN based on start and stop times. Other validation schemes, such as > examining fingerprints or watermarking of PSTN media, to show that a > domain received a particular PSTN phone call may also be considered by > the working group. The WG will select and standardize at least one > validation scheme. > > To help mitigate SPAM issues when using SIP between domains, the WG will > define a mechanisms to enable one domain to check that incoming SIP s/a mechanisms/a mechanism > messages from a different domain are coming from a domain that > successfully validated a phone number. The working group will define new > SIP headers and option tags to enable this. The key characteristic is not actually that validation had occurred, but rather, that the calling domain had previously placed a PSTN call to the number in question. > > The essential characteristic of ViPR is establishing authentication by > PSTN reachability when it is not possible to use a direct reference to > ENUM databases or other direct assertions of PSTN number > ownership. Elements such as public ENUM easily coexist with VIPR but no > direct interaction with ENUM will be required. I'd like to get a clear statement in here about the fact that ViPR is incrementally deployable using only existing interfaces to the PSTN. No change to PSTN capabilities, or new access to its databases, or support from PSTN providers, is required in any way. > > The problem statement and some possible starting points for solutions > are further discussed in the following internet drafts which shall form > the bases of the WG documents: > > draft-rosenberg-dispatch-vipr-overview > draft-rosenberg-dispatch-vipr-reload-usage > draft-rosenberg-dispatch-vipr-pvp > draft-rosenberg-dispatch-vipr-sip-antispam Add VAP. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From stpeter@stpeter.im Thu Jun 17 19:29:22 2010 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 BE6B03A6877 for ; Thu, 17 Jun 2010 19:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 NItxrMZeFL3y for ; Thu, 17 Jun 2010 19:29:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A5DC43A67AE for ; Thu, 17 Jun 2010 19:29:21 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 65AA9403F3 for ; Thu, 17 Jun 2010 20:29:26 -0600 (MDT) Message-ID: <4C1AD9FC.3090703@stpeter.im> Date: Thu, 17 Jun 2010 20:29:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: dispatch@ietf.org References: <4C1A26AE.2060401@cisco.com> In-Reply-To: <4C1A26AE.2060401@cisco.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010909000901050108060703" Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 18 Jun 2010 02:29:22 -0000 This is a cryptographically signed message in MIME format. --------------ms010909000901050108060703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/17/10 7:44 AM, Paul Kyzivat wrote: > Requiring all the categories to be specified in one URN has the downsid= e > that all category values need to be standardized as part of a single UR= N > spec. Conversely, consolidating multiple URNs gives the potential to > define a new category via an entirely new URN scheme.=20 To clarify, there is no such thing as a "URN scheme". Upon approval, draft-liess-dispatch-alert-info-urns will register a URN namespace identifier (NID) in accordance with RFC 3406, not a "URN scheme". Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010909000901050108060703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxODAyMjkxNlowIwYJKoZIhvcNAQkEMRYEFI7r1Lubg1q0j7oux9C+ U+udyv4SMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAIPvVM/B4nIgRxBbzb7kyqzAVHqXtfgRHVjkuSIi+ R8EAzzYqiEz+uYvSa15rT1JlC3p0qhAIVoT1TTHgu96zVXN5z7pdsLrsrqUpTC2mOnz9XqWp KaxDrsNS6It50RKgUXEb2fwTYeWROVhWtTBfDqaTgpJbjXBS9As6OIGSvKS74pkgCxJp0qU3 /Va2nFrFbox/igoYUTDtjlQKQ085Yay6vi8Cq+jzOjT4Wbm5IDHdB0s8L1zuAQiYSeJtOQIZ bDHHdmVhP4l6qGjgEXUunPG8yjagftelkr3VrFSLSkkXcgu9vGkfHGrHTWusIekmJBjhicO6 r28tU9GQvnuoGQAAAAAAAA== --------------ms010909000901050108060703-- From alexander.milinski@nsn.com Thu Jun 17 23:37:25 2010 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 D0C7A3A6949 for ; Thu, 17 Jun 2010 23:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyeZkN9CmtDn for ; Thu, 17 Jun 2010 23:37:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id F220E3A6920 for ; Thu, 17 Jun 2010 23:37:12 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5I6bGg8010436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Jun 2010 08:37:16 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5I6bFHS008084; Fri, 18 Jun 2010 08:37:15 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Jun 2010 08:37:15 +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, 18 Jun 2010 08:37:14 +0200 Message-ID: <3F4C11BC54A36642BFB5875D599F47BD02C29F77@DEMUEXC013.nsn-intra.net> In-Reply-To: <4C1AC71F.8070206@jdrosen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 2 - PSTN? Thread-Index: AcsOgthtbD6D7VzFTPWTrOee5Kg1BwALTcew References: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> <030501cb0e6e$babab220$30301660$%roni@huawei.com> <4C1AC71F.8070206@jdrosen.net> From: "Milinski, Alexander (NSN - DE/Munich)" To: "ext Jonathan Rosenberg" X-OriginalArrivalTime: 18 Jun 2010 06:37:15.0262 (UTC) FILETIME=[B0C059E0:01CB0EB0] Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 18 Jun 2010 06:37:25 -0000 Cullen, Jonathan, how is the PSTN defined in the sense of the charter? Does it include the SIP networks existing today, which are interconnected to the PSTN in the common sense (S=3D "switched"...) and you can reach by dialling a phone number? Regards, Alex =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Jonathan Rosenberg > Sent: Friday, June 18, 2010 3:09 AM > To: Roni Even > Cc: 'DISPATCH list' > Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? >=20 > Roni, >=20 > The key requirement of the solution is that: >=20 > 1. it be possible to validate the mapping of phone number to a domain=20 > which is "responsible" for that number, based on the=20 > definition Cullen=20 > has provided, and that >=20 > 2. such validation be possible using only access to publicly=20 > available=20 > open interfaces to the PSTN, so that the validation can be=20 > performed by=20 > any domain wishing to participate. >=20 > At the moment, the only publicly open interface to the PSTN is the=20 > ability to make a call. If you are aware of other open and publicly=20 > available interfaces by which we can perform validation, I'd love to=20 > hear about them :) >=20 > Thanks, > Jonathan R. >=20 > Roni Even wrote: > > Hi Cullen, > > I am sorry that you feel this way about me but I do not=20 > take this personally > > since I am used to being blamed on lots of things. > >=20 > > Maybe I was not clear about my view. > > Section 5.1 of the vipr overview provides the key=20 > properties that the > > solution requires and I think it is a very good summary of=20 > the requirements. > > I also think that dialing using E.164 numbers is better in=20 > many deployments. > > (My background in H.323 has led me to it and BTW I believe=20 > that any such > > solution can be applicable to H.323) > >=20 > > From this point the vipr overview suggests a solution that=20 > is hinted in the > > charter. > >=20 > > The question I have is if basing the validation of=20 > ownership of the PSTN > > number can only be based on an actual PSTN call or does the=20 > charter allow > > also other ways to validate the ownership of an E.164=20 > number and can this > > number be only the PSTN phone number or can it be other=20 > E.164 allocated > > without an attached PSTN capability.=20 > >=20 > > The proposed charter as I read it limits the scope to the=20 > case where the > > same number is used as the PSTN and SIP number. Did I=20 > understand correctly? > >=20 > >=20 > >=20 > > Roni Even > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > >> Behalf Of Cullen Jennings > >> Sent: Thursday, June 17, 2010 11:55 PM > >> To: Roni Even > >> Cc: 'DISPATCH list' > >> Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? > >> > >> > >> I'm having a real hard time actually understand what you=20 > are objecting > >> too. More inline ... > >> > >> On Jun 16, 2010, at 12:22 AM, Roni Even wrote: > >> > >>> Hi, > >>> I read the charter and the listed drafts. I have no=20 > problem with the > >> first > >>> two paragraph of the charter > >>> > >>> "There are two globally deployed address spaces for communications > >> that more > >>> than a billion people use on a daily basis. They are phone numbers > >> and DNS > >>> rooted address such as web servers and email addresses. The inter- > >> domain > >>> signaling design of SIP is primarily designed for email style > >> addresses yet > >>> a large percentage of SIP deployments mostly use phone numbers for > >>> identifying users. The goal of this working group is to=20 > enable inter- > >> domains > >>> communications over the internet, using protocol such as=20 > SIP, while > >> still > >>> allowing people to use phone numbers to identify the=20 > person they wish > >> to > >>> communicate with. > >>> > >>> The VIPR WG will address this problem by developing a peer to peer > >> based > >>> approach to finding domains that claim to be responsible=20 > for a given > >> phone > >>> number and validation protocols to ensure a reasonable likelihood > >> that a > >>> given domain actually is responsible for the phone number." > >>> > >>> I have a concern about using PSTN infrastructure for the > >> reachability. My > >>> understanding so far was that SIP is trying to provide a=20 > new way for > >> end to > >>> end communication that will replace the existing circuit switch > >>> infrastructure. This proposal says that the way to=20 > achieve end to end > >>> connectivity requires to have an end to end PSTN frastructure. > >> No this proposal says one of the way we can make PSTN=20 > address usable in > >> inter domain SIP is this. Clearly this approach would no longer be > >> valid when the PSTN was gone but by that point, presumably=20 > people would > >> be using more internet style address in SIP. Keep in mind the only > >> thing this work is trying to solve is mapping a PSTN address to a > >> internet address. When the PSTN is gone, that problem goes with it. > >> However the PSTN is far from gone - if I had to bet, I=20 > would guess that > >> phone numbers were around longer than v6 addresses (and than email > >> style address outlive them both). The issue is phone=20 > numbers are used > >> by humans which makes them very hard to transition off of=20 > while things > >> like v6 addresses are easier to transition off of as they=20 > are come and > >> go with the technologies that use them. My point being all these > >> addresses are around for a long time and the IETF works on=20 > standards to > >> help transition and interwork between them. The Telegram=20 > service was > >> emulated on top of ot > >> her technologies long after it had been supplanted by fax=20 > - the PSTN > >> will be similar. > >> > >>> The third paragraph is talking about validation using=20 > PSTN calls. I > >> think > >>> that we can look at validation of number ownership but should say > >> that > >>> requiring PSTN calls to do it is not the recommended approach. > >>> This will > >>> allow managing of PSTN numbers not in the scope of PSTN > >> infrastructure. Even > >>> the PSTN network is using external protocol like SS7 to=20 > route calls > >> using > >>> databases for achieving reachability so why not say we can use > >> similar > >>> infrastructure that will be IP based. > >> We did standardize and IP based database approach - it's=20 > called public > >> ENUM. However, from a practical point of view the only people that > >> could do the validations for ENUM are the carriers that have every > >> business incentive to not do it. Regulators do not have the right > >> incentives to regulate it into existence. VIPR on the=20 > other hand only > >> requires carriers to route calls. Routing calls is=20 > something they do > >> today, it is in their business interest so they will=20 > likely continue > >> doing it, and the regulation around common carriage often=20 > require them > >> to route calls. Both the existing regulations and=20 > economics favor that > >> the carriers will do what is needed to enable a solution=20 > that leverages > >> the PSTN for validation. > >> > >>> I can understand this as a temporary solution but not as=20 > a standard > >>> developed by the IETF. > >> How temporary do you think the PSTN is? How many years? =20 > Do you think > >> we should not be doing standards for WG like MARTINI that only WG > >> document limited itself to phone numbers? Should we not=20 > have standards > >> about SIP / PSTN interoperability? I don't hear you=20 > objecting to any of > >> the other work we do hat is "temporary" in the sense it is=20 > only useful > >> as long as the PSTN is around. > >> > >> Seriously, I read this and just feel like you are grasping=20 > at straws > >> for something to objet to since this proposal came from Cisco. > >> > >> > >>> > >>> Thanks > >>> > >>> Roni Even > >>> > >> _______________________________________________ > >> 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 > Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen > Chief Technology Strategist Mobile: +1=20 > (732) 766-2496 > Skype SkypeIn: +1=20 > (408) 465-0361 > jdrosen@skype.net http://www.skype.com > jdrosen@jdrosen.net http://www.jdrosen.net >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From pkyzivat@cisco.com Fri Jun 18 06:15:35 2010 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 A2C863A696A for ; Fri, 18 Jun 2010 06:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.253 X-Spam-Level: X-Spam-Status: No, score=-10.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDXd9wFCIBo2 for ; Fri, 18 Jun 2010 06:15:32 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 068213A6803 for ; Fri, 18 Jun 2010 06:15:31 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALsNG0xAZnwN/2dsb2JhbACDHZtycaZ6iSKRIYElgwZwBA X-IronPort-AV: E=Sophos;i="4.53,439,1272844800"; d="scan'208";a="122969172" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Jun 2010 13:15:37 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5IDFbFK027691; Fri, 18 Jun 2010 13:15:37 GMT Message-ID: <4C1B7179.9060904@cisco.com> Date: Fri, 18 Jun 2010 09:15:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <4C1A26AE.2060401@cisco.com> <4C1AD9FC.3090703@stpeter.im> In-Reply-To: <4C1AD9FC.3090703@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 18 Jun 2010 13:15:35 -0000 Peter, Ok - I couldn't remember the precise term and used something convenient. Thanks, Paul Peter Saint-Andre wrote: > On 6/17/10 7:44 AM, Paul Kyzivat wrote: > >> Requiring all the categories to be specified in one URN has the downside >> that all category values need to be standardized as part of a single URN >> spec. Conversely, consolidating multiple URNs gives the potential to >> define a new category via an entirely new URN scheme. > > To clarify, there is no such thing as a "URN scheme". Upon approval, > draft-liess-dispatch-alert-info-urns will register a URN namespace > identifier (NID) in accordance with RFC 3406, not a "URN scheme". > > Peter > > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jdrosen@jdrosen.net Fri Jun 18 06:52:47 2010 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 32A263A6908 for ; Fri, 18 Jun 2010 06:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.836, 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 ktyQlMNCKAV7 for ; Fri, 18 Jun 2010 06:52:45 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [173.205.124.201]) by core3.amsl.com (Postfix) with ESMTP id 559DC3A6831 for ; Fri, 18 Jun 2010 06:52:45 -0700 (PDT) Received: from pool-173-63-40-38.nwrknj.fios.verizon.net ([173.63.40.38] helo=[192.168.1.7]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OPbzb-0002Uu-Iq; Fri, 18 Jun 2010 09:52:24 -0400 Message-ID: <4C1B7A2E.3060906@jdrosen.net> Date: Fri, 18 Jun 2010 09:52:46 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Milinski, Alexander (NSN - DE/Munich)" References: <01a601cb0d1c$61ccd3d0$25667b70$%roni@huawei.com> <030501cb0e6e$babab220$30301660$%roni@huawei.com> <4C1AC71F.8070206@jdrosen.net> <3F4C11BC54A36642BFB5875D599F47BD02C29F77@DEMUEXC013.nsn-intra.net> In-Reply-To: <3F4C11BC54A36642BFB5875D599F47BD02C29F77@DEMUEXC013.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? 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, 18 Jun 2010 13:52:47 -0000 PSTN refers to the network which is the authoritative source of routing for calls made to E.164 numbers. Whether it uses SIP internally, or whether it provides SIP interfaces (aka SIP trunking), changes nothing. -Jonathan R. Milinski, Alexander (NSN - DE/Munich) wrote: > Cullen, Jonathan, > > how is the PSTN defined in the sense of the charter? > > Does it include the SIP networks existing today, which are > interconnected to the PSTN in the common sense (S= "switched"...) and > you can reach by dialling a phone number? > > Regards, > Alex > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Jonathan Rosenberg >> Sent: Friday, June 18, 2010 3:09 AM >> To: Roni Even >> Cc: 'DISPATCH list' >> Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? >> >> Roni, >> >> The key requirement of the solution is that: >> >> 1. it be possible to validate the mapping of phone number to a domain >> which is "responsible" for that number, based on the >> definition Cullen >> has provided, and that >> >> 2. such validation be possible using only access to publicly >> available >> open interfaces to the PSTN, so that the validation can be >> performed by >> any domain wishing to participate. >> >> At the moment, the only publicly open interface to the PSTN is the >> ability to make a call. If you are aware of other open and publicly >> available interfaces by which we can perform validation, I'd love to >> hear about them :) >> >> Thanks, >> Jonathan R. >> >> Roni Even wrote: >>> Hi Cullen, >>> I am sorry that you feel this way about me but I do not >> take this personally >>> since I am used to being blamed on lots of things. >>> >>> Maybe I was not clear about my view. >>> Section 5.1 of the vipr overview provides the key >> properties that the >>> solution requires and I think it is a very good summary of >> the requirements. >>> I also think that dialing using E.164 numbers is better in >> many deployments. >>> (My background in H.323 has led me to it and BTW I believe >> that any such >>> solution can be applicable to H.323) >>> >>> From this point the vipr overview suggests a solution that >> is hinted in the >>> charter. >>> >>> The question I have is if basing the validation of >> ownership of the PSTN >>> number can only be based on an actual PSTN call or does the >> charter allow >>> also other ways to validate the ownership of an E.164 >> number and can this >>> number be only the PSTN phone number or can it be other >> E.164 allocated >>> without an attached PSTN capability. >>> >>> The proposed charter as I read it limits the scope to the >> case where the >>> same number is used as the PSTN and SIP number. Did I >> understand correctly? >>> >>> >>> Roni Even >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Cullen Jennings >>>> Sent: Thursday, June 17, 2010 11:55 PM >>>> To: Roni Even >>>> Cc: 'DISPATCH list' >>>> Subject: Re: [dispatch] VIPR - proposed charter version 2 - PSTN? >>>> >>>> >>>> I'm having a real hard time actually understand what you >> are objecting >>>> too. More inline ... >>>> >>>> On Jun 16, 2010, at 12:22 AM, Roni Even wrote: >>>> >>>>> Hi, >>>>> I read the charter and the listed drafts. I have no >> problem with the >>>> first >>>>> two paragraph of the charter >>>>> >>>>> "There are two globally deployed address spaces for communications >>>> that more >>>>> than a billion people use on a daily basis. They are phone numbers >>>> and DNS >>>>> rooted address such as web servers and email addresses. The inter- >>>> domain >>>>> signaling design of SIP is primarily designed for email style >>>> addresses yet >>>>> a large percentage of SIP deployments mostly use phone numbers for >>>>> identifying users. The goal of this working group is to >> enable inter- >>>> domains >>>>> communications over the internet, using protocol such as >> SIP, while >>>> still >>>>> allowing people to use phone numbers to identify the >> person they wish >>>> to >>>>> communicate with. >>>>> >>>>> The VIPR WG will address this problem by developing a peer to peer >>>> based >>>>> approach to finding domains that claim to be responsible >> for a given >>>> phone >>>>> number and validation protocols to ensure a reasonable likelihood >>>> that a >>>>> given domain actually is responsible for the phone number." >>>>> >>>>> I have a concern about using PSTN infrastructure for the >>>> reachability. My >>>>> understanding so far was that SIP is trying to provide a >> new way for >>>> end to >>>>> end communication that will replace the existing circuit switch >>>>> infrastructure. This proposal says that the way to >> achieve end to end >>>>> connectivity requires to have an end to end PSTN frastructure. >>>> No this proposal says one of the way we can make PSTN >> address usable in >>>> inter domain SIP is this. Clearly this approach would no longer be >>>> valid when the PSTN was gone but by that point, presumably >> people would >>>> be using more internet style address in SIP. Keep in mind the only >>>> thing this work is trying to solve is mapping a PSTN address to a >>>> internet address. When the PSTN is gone, that problem goes with it. >>>> However the PSTN is far from gone - if I had to bet, I >> would guess that >>>> phone numbers were around longer than v6 addresses (and than email >>>> style address outlive them both). The issue is phone >> numbers are used >>>> by humans which makes them very hard to transition off of >> while things >>>> like v6 addresses are easier to transition off of as they >> are come and >>>> go with the technologies that use them. My point being all these >>>> addresses are around for a long time and the IETF works on >> standards to >>>> help transition and interwork between them. The Telegram >> service was >>>> emulated on top of ot >>>> her technologies long after it had been supplanted by fax >> - the PSTN >>>> will be similar. >>>> >>>>> The third paragraph is talking about validation using >> PSTN calls. I >>>> think >>>>> that we can look at validation of number ownership but should say >>>> that >>>>> requiring PSTN calls to do it is not the recommended approach. >>>>> This will >>>>> allow managing of PSTN numbers not in the scope of PSTN >>>> infrastructure. Even >>>>> the PSTN network is using external protocol like SS7 to >> route calls >>>> using >>>>> databases for achieving reachability so why not say we can use >>>> similar >>>>> infrastructure that will be IP based. >>>> We did standardize and IP based database approach - it's >> called public >>>> ENUM. However, from a practical point of view the only people that >>>> could do the validations for ENUM are the carriers that have every >>>> business incentive to not do it. Regulators do not have the right >>>> incentives to regulate it into existence. VIPR on the >> other hand only >>>> requires carriers to route calls. Routing calls is >> something they do >>>> today, it is in their business interest so they will >> likely continue >>>> doing it, and the regulation around common carriage often >> require them >>>> to route calls. Both the existing regulations and >> economics favor that >>>> the carriers will do what is needed to enable a solution >> that leverages >>>> the PSTN for validation. >>>> >>>>> I can understand this as a temporary solution but not as >> a standard >>>>> developed by the IETF. >>>> How temporary do you think the PSTN is? How many years? >> Do you think >>>> we should not be doing standards for WG like MARTINI that only WG >>>> document limited itself to phone numbers? Should we not >> have standards >>>> about SIP / PSTN interoperability? I don't hear you >> objecting to any of >>>> the other work we do hat is "temporary" in the sense it is >> only useful >>>> as long as the PSTN is around. >>>> >>>> Seriously, I read this and just feel like you are grasping >> at straws >>>> for something to objet to since this proposal came from Cisco. >>>> >>>> >>>>> Thanks >>>>> >>>>> Roni Even >>>>> >>>> _______________________________________________ >>>> 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. SkypeID: jdrosen >> Chief Technology Strategist Mobile: +1 >> (732) 766-2496 >> Skype SkypeIn: +1 >> (408) 465-0361 >> jdrosen@skype.net http://www.skype.com >> jdrosen@jdrosen.net http://www.jdrosen.net >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From stpeter@stpeter.im Fri Jun 18 07:07:11 2010 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 9728E28C0DB for ; Fri, 18 Jun 2010 07:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 tAB-HxF+FB4U for ; Fri, 18 Jun 2010 07:07:10 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 962F23A68A9 for ; Fri, 18 Jun 2010 07:07:10 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5AA4B403F3; Fri, 18 Jun 2010 08:07:15 -0600 (MDT) Message-ID: <4C1B7D88.7030600@stpeter.im> Date: Fri, 18 Jun 2010 08:07:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Kyzivat References: <4C1A26AE.2060401@cisco.com> <4C1AD9FC.3090703@stpeter.im> <4C1B7179.9060904@cisco.com> In-Reply-To: <4C1B7179.9060904@cisco.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030201010101020408030306" Cc: dispatch@ietf.org Subject: Re: [dispatch] Conceptual proposal for extensibility of Alert-Info URNs 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, 18 Jun 2010 14:07:11 -0000 This is a cryptographically signed message in MIME format. --------------ms030201010101020408030306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Understood. The term "branch of the URN tree" might be an informal way of describing a URN namespace identifier. But the charter proposal says "URN scheme", too, so I just wanted to nip that error in the bud. :) On 6/18/10 7:15 AM, Paul Kyzivat wrote: > Peter, >=20 > Ok - I couldn't remember the precise term and used something convenient= =2E >=20 > Thanks, > Paul >=20 > Peter Saint-Andre wrote: >> On 6/17/10 7:44 AM, Paul Kyzivat wrote: >> >>> Requiring all the categories to be specified in one URN has the downs= ide >>> that all category values need to be standardized as part of a single = URN >>> spec. Conversely, consolidating multiple URNs gives the potential to >>> define a new category via an entirely new URN scheme.=20 >> >> To clarify, there is no such thing as a "URN scheme". Upon approval, >> draft-liess-dispatch-alert-info-urns will register a URN namespace >> identifier (NID) in accordance with RFC 3406, not a "URN scheme". >> >> Peter >> >> --------------ms030201010101020408030306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxODE0MDcwNFowIwYJKoZIhvcNAQkEMRYEFO6Kr82TPtGObfoNJKtm bOP4dyrNMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEABI2uuj1whPTaSQdWtIdePeyWBX6Nni8HtjUen5lL NeQUPicxBIBDdMIdMM1ivBlqAjqAVsrFcnhzIBGSE/Sx2yyThU2S2jGpxkGaOo0OiB3zGARJ sbp+oAKM9MousM9nT9FE24WkLMFAyPm2P93KdpjamKeciSNsUXoaYOkeSgMEOpdEZZy+G/Kr roVzhVtYm9kW8kvJIOIMQb9mWa0mNRPK1nlELKFF6Mr4xnsvO3xEOkGKigzEqM299dnosaMS /gyi3Ok3po8B68QZLv+q8mzBUruxFmOLXbhbDponrcIFGkcfvhAkCtAs+AHi9seS6sCaqtYC UZCTFgqkZ7iRngAAAAAAAA== --------------ms030201010101020408030306-- From gonzalo.camarillo@ericsson.com Mon Jun 21 04:36:54 2010 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 B1C513A6A73 for ; Mon, 21 Jun 2010 04:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.183 X-Spam-Level: X-Spam-Status: No, score=-105.183 tagged_above=-999 required=5 tests=[AWL=1.416, 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 JF5EF1vstWgo for ; Mon, 21 Jun 2010 04:36:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A784A3A6A5E for ; Mon, 21 Jun 2010 04:36:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7b13ae0000071b2-13-4c1f4ed524d9 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 30.01.29106.5DE4F1C4; Mon, 21 Jun 2010 13:36:53 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jun 2010 13:36:20 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Jun 2010 13:36:20 +0200 Message-ID: <4C1F4EB4.3070509@ericsson.com> Date: Mon, 21 Jun 2010 14:36:20 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2010 11:36:20.0772 (UTC) FILETIME=[F8591E40:01CB1135] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Status of WGs proposed to be chartered 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, 21 Jun 2010 11:36:54 -0000 Folks, FYI: the IESG has just approved the charter proposals for disaggregated media, alert-info URNs, and user-to-user information for external review. I have already requested the start of the external review processes, which will start shortly. If you want to follow them, keep an eye on the IETF announce and IETF discussion mailing lists. Cheers, Gonzalo From mary.ietf.barnes@gmail.com Mon Jun 21 14:59:53 2010 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 5F37E3A67B8 for ; Mon, 21 Jun 2010 14:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 5FZ4rBy74oHM for ; Mon, 21 Jun 2010 14:59:52 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3569C3A6AF1 for ; Mon, 21 Jun 2010 14:59:52 -0700 (PDT) Received: by iwn9 with SMTP id 9so939403iwn.31 for ; Mon, 21 Jun 2010 14:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=O9p5hYbT4H8B+zFgvGKxwShBgTDtzpcvPOAZZTZLvu0=; b=GNFETVOH9rNUGKdWZ0XAjxf0/D5jgVOMIzHa6xPZ2dckeAjfE8tkY5tv1LjirDjWWU MflpM0A4SfI16cVZDKOuIamICFXwDWKDQv599sC8HwfhU9J9u3yG6Dr7PIWLLCriLrsF ELRNExHVvx4RX0TCVUmdbk47HcUN64afrvz9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RYhyxiUgZpRtU2UFwacqxV71MURch3Obb9aODY1UI+dUrqmQBl4iBF8caoDXu/Z7mo zsZpxuVhxwFMIzv1XQNJl34P28thcOTMY/L50uOEcWqAm0bq30yJ0GxTd0HrfEb1LDc6 hO90xJk9k2cQwInkU9YBdKlrwHDv95W8EiaZA= MIME-Version: 1.0 Received: by 10.231.120.150 with SMTP id d22mr5712536ibr.91.1277157596083; Mon, 21 Jun 2010 14:59:56 -0700 (PDT) Received: by 10.231.145.146 with HTTP; Mon, 21 Jun 2010 14:59:55 -0700 (PDT) In-Reply-To: <20100621214909.D25A428C13B@core3.amsl.com> References: <20100621214909.D25A428C13B@core3.amsl.com> Date: Mon, 21 Jun 2010 16:59:56 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [dispatch] Fwd: Nomcom 2010-2011: Second Call for Volunteers 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, 21 Jun 2010 21:59:53 -0000 Hi all, For folks that are not on the IETF announcement list, please consider volunteering for the 2010-2011 Nomcom. This is your opportunity to contribute to the community by participating in the selecting of the next set of leaders (IESG, IAB, IAOC and IETF chair). Thanks, Mary (as WG co-chair and Nomcom advisor for 2010-2011) ---------- Forwarded message ---------- From: NomCom Chair Date: Mon, Jun 21, 2010 at 4:49 PM Subject: Nomcom 2010-2011: Second Call for Volunteers To: IETF Announcement list Hi all, This is the Second call for Volunteers for the 2010-11 nomcom. =A0We are just about halfway through the volunteer period so if you are considering volunteering please do so very soon. I am pleased to report that we have 29 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! However, we need many more volunteers. =A0You have until 17:00 PDT (24:00 UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you volunteer as early as possible. =A0The more volunteers, the better chance w= e have of choosing a random yet representative cross section of the IETF pouplation. As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-73, IETF-74, IETF-75, IETF-76 and IETF-77. =A0If you qualify, and are willing t= o forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. =A0The details of the operation of nomcom may be found in RFC 3777. =A0The process on how to volunteer for nomcom is in the initial announcement: =A0https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The 29 volunteers who have thus far been qualified by the secretariat are: Fred Baker, Cisco Systems Stephan Wenger, Vidyo, Inc. Marc Blanchet, Viagenie Lixia Zhang, UCLA John Drake, Juniper Networks Ole Troan, Cisco Jiankang Yao, CNNIC Wassim Haddad, Ericsson Yi Zhao, Huawei USA Teemu Savolainen, Nokia Jouni Korhonen, Nokia Siemens Networks Mehmet Ersue, Nokia Siemens Networks Christian Schmidt, Nokia Siemens Networks Stephen Hanna, Juniper Networks Suresh Krishnan, Ericsson Eric Gray, Ericsson David Sinicrope, Ericsson Jan Melen, Ericsson Richard Barnes, BBN Technologies Hugo Salgado Hernandez, NIC Chile Ning Zong, Huawei Technologies Qin Wu, Huawei Technologies Karen Seo, BBN Technologies Haibin Song, Huawei Technologies Susan Hares, Huawei Technologies Tony Hansen. AT&T Labs Fuqing Huang, Huawei Technologies Co., Ltd. Huub van Helvoort, Huawei Technologies Miya Kohno, Juniper Networks The primary activity for this nomcom will begin just prior to IETF-78 in Maastricht and should be completed in early January 2011. =A0The nomcom wil= l be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, please consider that during the IETF meetings, people that do not attend would be expected to remotely participate during the day in the time zones of the meeting locations - Maastricht at the end of July and Beijing in November. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. =A0Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: =A0// As you enter in the IETF Registration Form, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// First/Given name followed by Last/Fam= ily Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// typically what goes in the Company fi= eld =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// in the IETF Registration Form [] =A0// =A0 =A0 =A0 =A0 // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. =A0If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From henry.sinnreich@gmail.com Tue Jun 22 08:30:34 2010 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 BEC4428C132 for ; Tue, 22 Jun 2010 08:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STAyODnudCAq for ; Tue, 22 Jun 2010 08:30:00 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 8717028C0DE for ; Tue, 22 Jun 2010 08:30:00 -0700 (PDT) Received: by gxk8 with SMTP id 8so305975gxk.31 for ; Tue, 22 Jun 2010 08:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:mime-version:content-type; bh=gJbiYz/4AVV6WkFA5s9JI7KRvzHLq2S9N6qXq87BM34=; b=Dl/qt1B14dmsXZWDUSoMv3ITO7qRxd8bEptMX0kOlBQ8z48s5HPkpkjhNSNDcnj6e+ LQGPdSvI6X15L0g6Gytxm3JkuSD8YMmQDCB1bHwvLGYEL1h91MUuXWs8tw1t7gTEMAw0 XRmd9VIgPjJZL7rR5OdkUgc1pZpVj6scBq0NA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:mime-version:content-type; b=XuksYwRaSpEostIvAJp8vVmXL6oeLPGII3nn15rOk1s043QNAR3iC90IAfk/rHNGX7 5rKEjfXDmJjKhl7YprCvXqRIB9eN8GGvyqqMh6Q/vMj+OCSnBmco+Ari91mqOCZRfb5l yyErL6hHCOvJgAxA3EMBFY4H/Y+zE/g7BGunI= Received: by 10.150.249.2 with SMTP id w2mr6166689ybh.243.1277220603225; Tue, 22 Jun 2010 08:30:03 -0700 (PDT) Received: from [192.168.0.34] (cpe-76-184-229-173.tx.res.rr.com [76.184.229.173]) by mx.google.com with ESMTPS id j3sm28205003ybe.19.2010.06.22.08.29.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Jun 2010 08:30:02 -0700 (PDT) User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 22 Jun 2010 10:29:56 -0500 From: Henry Sinnreich To: "dispatch@ietf.org" Message-ID: Thread-Topic: SIP APIs for Communications on the Web Thread-Index: AcsSH8R8Qbl7G2IJq0CoVk4eMq40lA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3360047400_16103206" Subject: [dispatch] SIP APIs for Communications on the Web 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, 22 Jun 2010 15:30:35 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3360047400_16103206 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Following the discussions on the Dispatch list in February and also in private, we have posted a new version of the I-D: http://www.ietf.org/id/draft-sinnreich-sip-web-apis-01.txt The clarifications include such topics as (in no particular order) * SIP and/or (vs.) XMPP/Jingle * HTML5 support for application scripts * Bidirectional HTTP, IETF "HyBi" WG * Hiding SIP complexity under the right, standards based API * Drawing the line between basic usage scenarios for a simple API and yet how to support complex VoIP call flows * The SIP state machine moves to the business logic in UA and Web feature servers; which is preferable * The traffic and time spent with web applications far surpasses the time t= o talk on the phone (exceptions) * Added references for metadata standards to replace SDP * SDPng was already proposed in the early =8C90s * Keep only UDP for media transport, RTP data about the media is moved to the application as well * New reference for HIP specific NAT traversal utilities. Please let us know how you feel these and other issues have been addressed. Abstract This memo describes a standards based approach to enable web based interactive multimedia communications. The objective is giving web developers the software tools to add communication widgets to web pages. The proposed SIP API does not necessarily require SIP protocol expertise by web developers for basic multimedia communications though it can be extended to port complex VoIP services to the web. The SIP API can also support the transition from network infrastructure based VoIP to rich web based communications. The benefits of the formal REST architecture of the web are extended to real time communications. Only two standard application layer protocols are required: HTTP for signaling data communications such as in SIP and/or XMPP and UDP for real time media transport. We consider replacing SDP with metadata about media, displays and user controls. RTP data functionality can also be moved to the application itself. NAT traversal and other functions are delegated to HIP. Thanks, Henry --B_3360047400_16103206 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable SIP APIs for Communications on the Web Following the discussions on the Dispatch list in February and also in pri= vate, we have posted a new version of the I-D:

http:/= /www.ietf.org/id/draft-sinnreich-sip-web-apis-01.txt

The clarifications include such topics as (in no particular order)
  • SIP and/or (vs.) XMPP/Jingle
  • HTML5 support for application scripts=20
  • Bidirectional HTTP, IETF "HyBi" WG
  • Hiding SIP complexity under the right, standards based API
  • Drawing the line between basic usage scenarios for a sim= ple API and yet how to support complex VoIP call flows
  • The SIP state machine moves to the business logic in UA = and Web feature servers; which is preferable
  • The traffic and time spent with web applications far sur= passes the time to talk on the phone (exceptions)
  • Added references for metadata standards to replace SDP
  • SDPng was already proposed in the early ‘90s
  • Keep only UDP for media transport, RTP data about the me= dia is moved to the application as well
  • New reference for HIP specific NAT traversal utilities.<= BR>

Please let us know how you feel these and other issues have been addressed.=

Abstract

   This memo describes a standards based approach to enable = web based
   interactive multimedia communications.  The objectiv= e is giving web
   developers the software tools to add communication widget= s to web
   pages.

   The proposed SIP API does not necessarily require SIP pro= tocol
   expertise by web developers for basic multimedia communic= ations
   though it can be extended to port complex VoIP services t= o the web.
   The SIP API can also support the transition from network<= BR>    infrastructure based VoIP to rich web based communication= s.

   The benefits of the formal REST architecture of the web a= re extended
   to real time communications.

   Only two standard application layer protocols are require= d: HTTP for
   signaling data communications such as in SIP and/or XMPP = and UDP for
   real time media transport. We consider replacing SDP with= metadata
   about media, displays and user controls.

   RTP data functionality can also be moved to the applicati= on itself.
   NAT traversal and other functions are delegated to HIP.
Thanks,
Henry --B_3360047400_16103206-- From R.Jesske@telekom.de Wed Jun 23 00:33:55 2010 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 A43E63A679C for ; Wed, 23 Jun 2010 00:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, NORMAL_HTTP_TO_IP=0.001, 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 yfqUW+ZvOgii for ; Wed, 23 Jun 2010 00:33:53 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id BEE593A6A44 for ; Wed, 23 Jun 2010 00:33:50 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 23 Jun 2010 09:32:52 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 09:32:33 +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: Wed, 23 Jun 2010 09:32:32 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reason In responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKogA9AH9jABpml4wAGDoqZg References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> From: To: , X-OriginalArrivalTime: 23 Jun 2010 07:32:33.0960 (UTC) FILETIME=[3EEA3A80:01CB12A6] Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) 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, 23 Jun 2010 07:33:55 -0000 Hi John, After reading this thread again, I would like to propose two = requirements as follows: REQ-1: It should be possible to support PSTN-SIP-PSTN scenarios where the = reason of a call release can be transferred though the SIP domain = without any loss of information and no change of reason. -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: 07 June 2010 06:59 > To: Elwell, John; dispatch@ietf.org > Subject: AW: Reason In=20 > responses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Hi John, > Thank you for your comments: > Here are my view. >=20 > REQ-1: > I think that REQ-1 is still a justification, because not each=20 > Operator will use SIP-T for tunnelling purposes. > If you pass an untrusted domain SIP-T should not part,=20 > because it could include restricted numbers or other=20 > information that should not be presented to untrusted networks. >=20 > Also only for passing the Q.850 Cause code to encapsulate the=20 > whole ISUP is a little over dimensioned. > The SIP-T MIME can be lost due to the interdomain trust=20 > relation ships which the Reason header cannot. >=20 > For in an multi carrier/service provider environment like=20 > Germany is, it will not be secure that each operator will=20 > support SIP-T.=20 [JRE] This helps to explain why SIP-T is not sufficient. IF SIP-T = requires you to include additional information that you may not want to = include when going outside a domain, that would be a reason for = requiring a different solution. This was not made clear before. John >=20 > REQ-2 > It must be possible to provide an accurate indication to a=20 > UAC, so that the UAC can provide a suitable indication to the=20 > user. >=20 > So that is the proposal for REQ-2. >=20 > REQ-3=20 > A UA may have the ability to display ISUP specific release=20 > causes or > show a equivalent text. >=20 > So that would be sufficient enough for REQ-3. If people would=20 > like to see such text. >=20 > REQ-3/4 > Your comment with regard to the type of UA is correct. I=20 > tried to satisfy people. The fact is that is not intended to=20 > include the Q.850 cause by an SIP end device. So the=20 > conclusion is changing REQ-3 and deleting REQ-4. >=20 > So now I would like to ask the people which requirements they=20 > would like to see in the draft. > As I understand John he sees only one (REQ-2) >=20 > I propose REQ-1, -2 and -3. >=20 > Opinions? >=20 > Thank you and Best Regards >=20 > Roland >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einf=FChrung > Roland Jesske > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628-2766 (Tel.) > +49 521 9210-3753 (Fax) > +49 171 8618-445 (Mobil) > E-Mail: mailto:r.jesske@telekom.de > http://www.telekom.com =20 >=20 > Erleben, was verbindet.=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 >=20 > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > nicht jede E-Mail drucken. >=20 > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Gesendet: Dienstag, 18. Mai 2010 21:37 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: Reason In=20 > responses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Roland,=20 >=20 > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > > Sent: 18 May 2010 15:57 > > To: Elwell, John; dispatch@ietf.org > > Subject: AW: Reason In=20 > > responses(draft-jesske-dispatch-reason-in-responses-02) > >=20 > > Hi John, > > Thank you for your comments.=20 > > It was asked to split the draft into requirements and at=20 > > least procedures. > >=20 > > You are right that within the requirements draft is more that=20 > > requirements. It is also the motivation, justification and=20 > > examples. I can change the title if people are happy with it.=20 > > Question is if such a draft is also needed as RFC or if it=20 > > only seen as a temporary document during the discussion. > [JRE] I was not proposing a title change, and I have no=20 > problem combining motivation with requirements, although I do=20 > feel the examples look too much like solution and are=20 > unnecessary. Although some people asked you to split the=20 > draft, in my opinion it was wasted effort, but it is done now. >=20 > >=20 > > With regard to REQ-1 I propose the following re-wording: > >=20 > > It should be possible to support within native SIP=20 > > environment PSTN-SIP-PSTN scenarios where the reason of a=20 > > call release can be transferred though the SIP domain > > without any loss of information and no change of reason. > >=20 > > I think this was discussed lengthy during the last meeting=20 > > and email discussion. > > Not each PSTN GW will support ISUP MIME encapsulation. At=20 > > least the 3GPP IMS has no SIP. The IMS is not using SIP-T. > [JRE] I don't think the new wording makes any difference.=20 > SIP-T is a means for tunnelling a Q.850 cause through a=20 > native SIP domain. The IETF already defines SIP-T as the=20 > solution, and if this solution is not sufficient, you need to=20 > cite reasons why not and identify a requirement that cannot=20 > be met using SIP-T. Just saying that IMS does not use SIP-T=20 > doesn't sound like a sufficient reason to me, because clearly=20 > IMS could be made to use SIP-T. >=20 > To be clear, I am not saying that the Reason header field=20 > should not be used in this situation, if the header field is=20 > defined for use in responses in general in order meet other=20 > requirements. I am simply saying that REQ-1 is not sufficient=20 > justification for allowing the Reason header field in=20 > responses, since REQ-1 can be satisfied using an existing mechanism. >=20 >=20 > >=20 > > REQ-2 and REQ-3 > > Yes it looks similar. > >=20 > > REQ-3 was added because it was seen from user device=20 > > perspective that the Device have the possibility to show the=20 > > Q.850 cause but that such a End Device does not include Q.850=20 > > causes. Of course a MGC should have this possibility. > >=20 > > I would be happy to shrink REQ-2 and 3 to your proposed text. > >=20 > > REQ-2 > > It must be possible to provide an accurate indication to a=20 > > UAC, so that the UAC can provide a suitable indication to the=20 > > user. Whether this be an announcement, a textual message, an=20 > > icon, a flashing lamp, a tone, a vibration, an odour or=20 > > whatever, is a user interface matter. > [JRE] I did not intend the second sentence to be part of the=20 > requirement - it was just for illustration of why the=20 > existing text, which focused on textual display, was inadequate. >=20 > >=20 > > REQ-4 was the consequence of REQ-3 where we do not allow the=20 > > inclusion of a Q850 cause by a end device. > >=20 > > So the trick is not allow the SIP end device to include a=20 > > Q850 cause and in some certain cases to allow an service=20 > > provider controlled application server to include a Reason=20 > > header with a Q.850 cause. But it should not be done=20 > > generally by SIP applications. So normally a ISUP=20 > > implementation will use ISUP causes but not SIP implementations. > > But there are SIP Application servers out in the world that=20 > > will have a ISUP application (or ISUP like application that=20 > > reacts and behaves as within a ISUP network). > [JRE] I found REQ-3 rather confusing. On re-reading it, the=20 > first sentence is a requirement concerning reception, and the=20 > second sentence seems (if I understand correctly) to be a=20 > statement about sending. Assuming my understanding is=20 > correct, making a statement, within a requirement, that=20 > something is out of scope seems to suggest it is not part of=20 > the requirement. >=20 > In addition, the way SIP is specified, there is no real=20 > distinction between different types of UA. In other words,=20 > SIP procedures for UAs apply to UAs in general, not to=20 > specific types of UA like ASs. So writing a requirement that=20 > tries to distinguish between different types of UA does not=20 > seem to make sense. >=20 > >=20 > > Question is now how to proceed further. > >=20 > > Are people happy to have the documents split or put again=20 > > together with striking out the examples ect? > > Or to have the documents as they are with some transfer of=20 > > text to the draft-jesske-dispatch-reason-in-responses-02 draft? > [JRE] I don't have a strong opinion about document structure,=20 > although my personal preference would have been to leave it=20 > as one document, as it was originally. My main concern is=20 > trying to come up with a meaningful set of requirements, and=20 > in my opinion it reduces to a single requirement - being able=20 > to convey a Q.850 cause from PSTN (or similar) to a UAC so=20 > that the UAC can render meaningful information to the user. >=20 > John >=20 >=20 > >=20 > > Comments? > >=20 > > Thank you and Best Regards > >=20 > > Roland > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Gesendet: Donnerstag, 13. Mai 2010 09:24 > > An: Jesske, Roland; dispatch@ietf.org > > Betreff: RE: Reason In=20 > > responses(draft-jesske-dispatch-reason-in-responses-02) > >=20 > > Roland, > >=20 > > In my view, there is a simple requirement to convey Q.850=20 > > causes in SIP response messages, so that the UAC will receive=20 > > a more accurate indication of the reason for rejection when=20 > > rejection comes from PSTN. The cause mapping table helps to=20 > > illustrate this. This is not rocket science, and I am=20 > > disappointed that we have not found a quick way of=20 > > dispatching this and just getting the work done. In my=20 > > opinion the split into separate documents was unnecessary=20 > > (take as an example the recently-published RFC 5876, which=20 > > combines motivation and solution in one document), but it has=20 > > been done now. Unfortunately I don't think it has moved us=20 > > any further forward. > >=20 > > I don't think the requirements in section 3 are particularly=20 > > well expressed. REQ-1 can already be met by tunnelling in=20 > > accordance with SIP-T. I would not expect the IETF to provide=20 > > a new solution specifically for that requirement. > >=20 > > I think REQ-2 and REQ-3 boil down to the same thing - it must=20 > > be possible to provide an accurate indication to a UAC, so=20 > > that the UAC can provide a suitable indication to the user.=20 > > Whether this be an announcement, a textual message, an icon,=20 > > a flashing lamp, a tone, a vibration, an odour or whatever,=20 > > is a user interface matter. > >=20 > > I also find REQ-4 rather problematic. If we have a solution=20 > > for PSTN, we would also have a solution for some other form=20 > > of gateway into a domain that provides a "PSTN-like service".=20 > > Unfortunately, if you try to bring this out as a separate=20 > > requirement, it raises the question of what exactly is this=20 > > "PSTN-like service", and if it is somehow SIP-based, why it=20 > > needs to be "PSTN-like", and so on. > >=20 > > Basically I think there is only a single requirement here -=20 > > provision of a correct indication to a UAC when rejection=20 > > comes from the PSTN. I think that is a reasonable requirement=20 > > and we should just go ahead and do it, rather like we did=20 > > with RFC 5876 when we extended the range of messages that=20 > > PAI/PPI could be used in. > >=20 > > I find the statement in REQ-3 "A inclusion of [Q.850] causes=20 > > is out of scope." very strange. I thought the whole idea was=20 > > to convey Q.850 causes, so why say they are out of scope? I=20 > > assume this is some sort of typo. > >=20 > > I think one of the consequences of deciding to split=20 > > requirements and solution into separate drafts is that the=20 > > requirements draft has to stick to motivation and=20 > > requirements. I find too much in the draft (particularly the=20 > > examples) that smells of solution. > >=20 > > John > >=20 > >=20 > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 > R.Jesske@telekom.de > > > Sent: 13 May 2010 03:05 > > > To: dispatch@ietf.org > > > Subject: Re: [dispatch] Reason In responses=20 > > > (draft-jesske-dispatch-reason-in-responses-02) > > >=20 > > > Dear all,=20 > > > I have asked for comments on the two drafts mentioned below.=20 > > > So far I didn't get any. Does that mean that people are happy=20 > > > now with the content and we could proceed with it?=20 > > >=20 > > > Thank you and Best Regrads=20 > > >=20 > > > Roland=20 > > >=20 > > >=20 > > > _____________________________________________=20 > > > Von: Jesske, Roland =20 > > > Gesendet: Donnerstag, 8. April 2010 09:46=20 > > > An: dispatch@ietf.org=20 > > > Betreff: Reason In responses=20 > > > (draft-jesske-dispatch-reason-in-responses-02)=20 > > >=20 > > > Dear all,=20 > > > During the discussion concerning the Reason header field in=20 > > > Responses I was asked to split the document into an=20 > > > requirements part and an protocol part. > > >=20 > > > So please feel free to comment on the drafts.=20 > > >=20 > > > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-respo > > > nses-02=20 > > > > > onses-02> =20 > > >=20 > > > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-r > > > esponses-00=20 > > > > > responses-00> =20 > > >=20 > > > Best regards=20 > > >=20 > > > Roland Jesske=20 > > >=20 > > >=20 > > > Deutsche Telekom Netzproduktion GmbH=20 > > > Zentrum Technik Einf=FChrung=20 > > > Roland Jesske=20 > > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > > > +49 6151 628-2766 (Tel.)=20 > > > +49 521 9210-3753 (Fax)=20 > > > +49 171 8618-445 (Mobil)=20 > > > E-Mail: r.jesske@telekom.de =20 > > > www.telekom.com =20 > > >=20 > > > Erleben, was verbindet.=20 > > >=20 > > > Deutsche Telekom Netzproduktion GmbH=20 > > > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 > > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > > > Albert Matheis, Klaus Peren=20 > > > Handelsregister: Amtsgericht Bonn HRB 14190=20 > > > Sitz der Gesellschaft: Bonn=20 > > > USt-IdNr. DE 814645262=20 > > >=20 > > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > > > nicht jede E-Mail drucken.=20 > > >=20 > > >=20 > > >=20 > >=20 >=20 From john.elwell@siemens-enterprise.com Wed Jun 23 05:28:41 2010 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 3AAE43A683D for ; Wed, 23 Jun 2010 05:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=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 CDk8R7IyQpdh for ; Wed, 23 Jun 2010 05:28:38 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 318CD3A6989 for ; Wed, 23 Jun 2010 05:28:37 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-605174; Wed, 23 Jun 2010 14:28:44 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D93E823F028E; Wed, 23 Jun 2010 14:28:44 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 23 Jun 2010 14:28:44 +0200 From: "Elwell, John" To: "R.Jesske@telekom.de" , "dispatch@ietf.org" Date: Wed, 23 Jun 2010 14:28:43 +0200 Thread-Topic: Reason In responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKogA9AH9jABpml4wAGDoqZgAAqOW3A= Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) 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, 23 Jun 2010 12:28:41 -0000 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: 23 June 2010 08:33 > To: Elwell, John; dispatch@ietf.org > Subject: AW: Reason In > responses(draft-jesske-dispatch-reason-in-responses-02) > > Hi John, > After reading this thread again, I would like to propose two > requirements as follows: > > REQ-1: > It should be possible to support PSTN-SIP-PSTN scenarios > where the reason of a call release can be transferred though > the SIP domain without any loss of information and no change > of reason. > REQ-2: > It must be possible to provide an accurate indication to a > UAC, so that the UAC can provide a suitable indication > to the user. > > > > As an additional Option there could be a third one as follows: > > REQ-3: > > UA may have the ability to display ISUP specific release > causes or show a equivalent text. [JRE] This has no impact on the protocol and therefore is out of scope. John > > > Please indicate if you see this RE-3 within the scope or if > it is already covered by REQ-2. > > Opinions. > > If people are happy I will provide an updated draft. > > Best Regards > > Roland > > > > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > Roland Jesske > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628-2766 (Tel.) > +49 521 9210-3753 (Fax) > +49 171 8618-445 (Mobil) > E-Mail: r.jesske@telekom.de > www.telekom.com > > Erleben, was verbindet. > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), > Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und > nicht jede E-Mail drucken. > > > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Gesendet: Dienstag, 15. Juni 2010 16:28 > An: Jesske, Roland; dispatch@ietf.org > Betreff: RE: Reason In > responses(draft-jesske-dispatch-reason-in-responses-02) > > > > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: 07 June 2010 06:59 > > To: Elwell, John; dispatch@ietf.org > > Subject: AW: Reason In > > responses(draft-jesske-dispatch-reason-in-responses-02) > > > > Hi John, > > Thank you for your comments: > > Here are my view. > > > > REQ-1: > > I think that REQ-1 is still a justification, because not each > > Operator will use SIP-T for tunnelling purposes. > > If you pass an untrusted domain SIP-T should not part, > > because it could include restricted numbers or other > > information that should not be presented to untrusted networks. > > > > Also only for passing the Q.850 Cause code to encapsulate the > > whole ISUP is a little over dimensioned. > > The SIP-T MIME can be lost due to the interdomain trust > > relation ships which the Reason header cannot. > > > > For in an multi carrier/service provider environment like > > Germany is, it will not be secure that each operator will > > support SIP-T. > [JRE] This helps to explain why SIP-T is not sufficient. IF > SIP-T requires you to include additional information that you > may not want to include when going outside a domain, that > would be a reason for requiring a different solution. This > was not made clear before. > > John > > > > > REQ-2 > > It must be possible to provide an accurate indication to a > > UAC, so that the UAC can provide a suitable indication to the > > user. > > > > So that is the proposal for REQ-2. > > > > REQ-3 > > A UA may have the ability to display ISUP specific release > > causes or > > show a equivalent text. > > > > So that would be sufficient enough for REQ-3. If people would > > like to see such text. > > > > REQ-3/4 > > Your comment with regard to the type of UA is correct. I > > tried to satisfy people. The fact is that is not intended to > > include the Q.850 cause by an SIP end device. So the > > conclusion is changing REQ-3 and deleting REQ-4. > > > > So now I would like to ask the people which requirements they > > would like to see in the draft. > > As I understand John he sees only one (REQ-2) > > > > I propose REQ-1, -2 and -3. > > > > Opinions? > > > > Thank you and Best Regards > > > > Roland > > > > > > Deutsche Telekom Netzproduktion GmbH > > Zentrum Technik Einf=FChrung > > Roland Jesske > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > > +49 6151 628-2766 (Tel.) > > +49 521 9210-3753 (Fax) > > +49 171 8618-445 (Mobil) > > E-Mail: mailto:r.jesske@telekom.de > > http://www.telekom.com > > > > Erleben, was verbindet. > > > > Deutsche Telekom Netzproduktion GmbH > > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), > > Albert Matheis, Klaus Peren > > Handelsregister: Amtsgericht Bonn HRB 14190 > > Sitz der Gesellschaft: Bonn > > USt-IdNr. DE 814645262 > > > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und > > nicht jede E-Mail drucken. > > > > -----Urspr=FCngliche Nachricht----- > > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Gesendet: Dienstag, 18. Mai 2010 21:37 > > An: Jesske, Roland; dispatch@ietf.org > > Betreff: RE: Reason In > > responses(draft-jesske-dispatch-reason-in-responses-02) > > > > Roland, > > > > > -----Original Message----- > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > Sent: 18 May 2010 15:57 > > > To: Elwell, John; dispatch@ietf.org > > > Subject: AW: Reason In > > > responses(draft-jesske-dispatch-reason-in-responses-02) > > > > > > Hi John, > > > Thank you for your comments. > > > It was asked to split the draft into requirements and at > > > least procedures. > > > > > > You are right that within the requirements draft is more that > > > requirements. It is also the motivation, justification and > > > examples. I can change the title if people are happy with it. > > > Question is if such a draft is also needed as RFC or if it > > > only seen as a temporary document during the discussion. > > [JRE] I was not proposing a title change, and I have no > > problem combining motivation with requirements, although I do > > feel the examples look too much like solution and are > > unnecessary. Although some people asked you to split the > > draft, in my opinion it was wasted effort, but it is done now. > > > > > > > > With regard to REQ-1 I propose the following re-wording: > > > > > > It should be possible to support within native SIP > > > environment PSTN-SIP-PSTN scenarios where the reason of a > > > call release can be transferred though the SIP domain > > > without any loss of information and no change of reason. > > > > > > I think this was discussed lengthy during the last meeting > > > and email discussion. > > > Not each PSTN GW will support ISUP MIME encapsulation. At > > > least the 3GPP IMS has no SIP. The IMS is not using SIP-T. > > [JRE] I don't think the new wording makes any difference. > > SIP-T is a means for tunnelling a Q.850 cause through a > > native SIP domain. The IETF already defines SIP-T as the > > solution, and if this solution is not sufficient, you need to > > cite reasons why not and identify a requirement that cannot > > be met using SIP-T. Just saying that IMS does not use SIP-T > > doesn't sound like a sufficient reason to me, because clearly > > IMS could be made to use SIP-T. > > > > To be clear, I am not saying that the Reason header field > > should not be used in this situation, if the header field is > > defined for use in responses in general in order meet other > > requirements. I am simply saying that REQ-1 is not sufficient > > justification for allowing the Reason header field in > > responses, since REQ-1 can be satisfied using an existing mechanism. > > > > > > > > > > REQ-2 and REQ-3 > > > Yes it looks similar. > > > > > > REQ-3 was added because it was seen from user device > > > perspective that the Device have the possibility to show the > > > Q.850 cause but that such a End Device does not include Q.850 > > > causes. Of course a MGC should have this possibility. > > > > > > I would be happy to shrink REQ-2 and 3 to your proposed text. > > > > > > REQ-2 > > > It must be possible to provide an accurate indication to a > > > UAC, so that the UAC can provide a suitable indication to the > > > user. Whether this be an announcement, a textual message, an > > > icon, a flashing lamp, a tone, a vibration, an odour or > > > whatever, is a user interface matter. > > [JRE] I did not intend the second sentence to be part of the > > requirement - it was just for illustration of why the > > existing text, which focused on textual display, was inadequate. > > > > > > > > REQ-4 was the consequence of REQ-3 where we do not allow the > > > inclusion of a Q850 cause by a end device. > > > > > > So the trick is not allow the SIP end device to include a > > > Q850 cause and in some certain cases to allow an service > > > provider controlled application server to include a Reason > > > header with a Q.850 cause. But it should not be done > > > generally by SIP applications. So normally a ISUP > > > implementation will use ISUP causes but not SIP implementations. > > > But there are SIP Application servers out in the world that > > > will have a ISUP application (or ISUP like application that > > > reacts and behaves as within a ISUP network). > > [JRE] I found REQ-3 rather confusing. On re-reading it, the > > first sentence is a requirement concerning reception, and the > > second sentence seems (if I understand correctly) to be a > > statement about sending. Assuming my understanding is > > correct, making a statement, within a requirement, that > > something is out of scope seems to suggest it is not part of > > the requirement. > > > > In addition, the way SIP is specified, there is no real > > distinction between different types of UA. In other words, > > SIP procedures for UAs apply to UAs in general, not to > > specific types of UA like ASs. So writing a requirement that > > tries to distinguish between different types of UA does not > > seem to make sense. > > > > > > > > Question is now how to proceed further. > > > > > > Are people happy to have the documents split or put again > > > together with striking out the examples ect? > > > Or to have the documents as they are with some transfer of > > > text to the draft-jesske-dispatch-reason-in-responses-02 draft? > > [JRE] I don't have a strong opinion about document structure, > > although my personal preference would have been to leave it > > as one document, as it was originally. My main concern is > > trying to come up with a meaningful set of requirements, and > > in my opinion it reduces to a single requirement - being able > > to convey a Q.850 cause from PSTN (or similar) to a UAC so > > that the UAC can render meaningful information to the user. > > > > John > > > > > > > > > > Comments? > > > > > > Thank you and Best Regards > > > > > > Roland > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Gesendet: Donnerstag, 13. Mai 2010 09:24 > > > An: Jesske, Roland; dispatch@ietf.org > > > Betreff: RE: Reason In > > > responses(draft-jesske-dispatch-reason-in-responses-02) > > > > > > Roland, > > > > > > In my view, there is a simple requirement to convey Q.850 > > > causes in SIP response messages, so that the UAC will receive > > > a more accurate indication of the reason for rejection when > > > rejection comes from PSTN. The cause mapping table helps to > > > illustrate this. This is not rocket science, and I am > > > disappointed that we have not found a quick way of > > > dispatching this and just getting the work done. In my > > > opinion the split into separate documents was unnecessary > > > (take as an example the recently-published RFC 5876, which > > > combines motivation and solution in one document), but it has > > > been done now. Unfortunately I don't think it has moved us > > > any further forward. > > > > > > I don't think the requirements in section 3 are particularly > > > well expressed. REQ-1 can already be met by tunnelling in > > > accordance with SIP-T. I would not expect the IETF to provide > > > a new solution specifically for that requirement. > > > > > > I think REQ-2 and REQ-3 boil down to the same thing - it must > > > be possible to provide an accurate indication to a UAC, so > > > that the UAC can provide a suitable indication to the user. > > > Whether this be an announcement, a textual message, an icon, > > > a flashing lamp, a tone, a vibration, an odour or whatever, > > > is a user interface matter. > > > > > > I also find REQ-4 rather problematic. If we have a solution > > > for PSTN, we would also have a solution for some other form > > > of gateway into a domain that provides a "PSTN-like service". > > > Unfortunately, if you try to bring this out as a separate > > > requirement, it raises the question of what exactly is this > > > "PSTN-like service", and if it is somehow SIP-based, why it > > > needs to be "PSTN-like", and so on. > > > > > > Basically I think there is only a single requirement here - > > > provision of a correct indication to a UAC when rejection > > > comes from the PSTN. I think that is a reasonable requirement > > > and we should just go ahead and do it, rather like we did > > > with RFC 5876 when we extended the range of messages that > > > PAI/PPI could be used in. > > > > > > I find the statement in REQ-3 "A inclusion of [Q.850] causes > > > is out of scope." very strange. I thought the whole idea was > > > to convey Q.850 causes, so why say they are out of scope? I > > > assume this is some sort of typo. > > > > > > I think one of the consequences of deciding to split > > > requirements and solution into separate drafts is that the > > > requirements draft has to stick to motivation and > > > requirements. I find too much in the draft (particularly the > > > examples) that smells of solution. > > > > > > John > > > > > > > > > > -----Original Message----- > > > > From: dispatch-bounces@ietf.org > > > > [mailto:dispatch-bounces@ietf.org] On Behalf Of > > R.Jesske@telekom.de > > > > Sent: 13 May 2010 03:05 > > > > To: dispatch@ietf.org > > > > Subject: Re: [dispatch] Reason In responses > > > > (draft-jesske-dispatch-reason-in-responses-02) > > > > > > > > Dear all, > > > > I have asked for comments on the two drafts mentioned below. > > > > So far I didn't get any. Does that mean that people are happy > > > > now with the content and we could proceed with it? > > > > > > > > Thank you and Best Regrads > > > > > > > > Roland > > > > > > > > > > > > _____________________________________________ > > > > Von: Jesske, Roland > > > > Gesendet: Donnerstag, 8. April 2010 09:46 > > > > An: dispatch@ietf.org > > > > Betreff: Reason In responses > > > > (draft-jesske-dispatch-reason-in-responses-02) > > > > > > > > Dear all, > > > > During the discussion concerning the Reason header field in > > > > Responses I was asked to split the document into an > > > > requirements part and an protocol part. > > > > > > > > So please feel free to comment on the drafts. > > > > > > > > http://64.170.98.42/html/draft-jesske-dispatch-reason-in-respo > > > > nses-02 > > > > > > > onses-02> > > > > > > > > http://64.170.98.42/html/draft-jesske-dispatch-req-reason-in-r > > > > esponses-00 > > > > > > > responses-00> > > > > > > > > Best regards > > > > > > > > Roland Jesske > > > > > > > > > > > > Deutsche Telekom Netzproduktion GmbH > > > > Zentrum Technik Einf=FChrung > > > > Roland Jesske > > > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > > > > +49 6151 628-2766 (Tel.) > > > > +49 521 9210-3753 (Fax) > > > > +49 171 8618-445 (Mobil) > > > > E-Mail: r.jesske@telekom.de > > > > www.telekom.com > > > > > > > > Erleben, was verbindet. > > > > > > > > Deutsche Telekom Netzproduktion GmbH > > > > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > > > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), > > > > Albert Matheis, Klaus Peren > > > > Handelsregister: Amtsgericht Bonn HRB 14190 > > > > Sitz der Gesellschaft: Bonn > > > > USt-IdNr. DE 814645262 > > > > > > > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und > > > > nicht jede E-Mail drucken. > > > > > > > > > > > > > > > > > > From dworley@avaya.com Wed Jun 23 09:35:33 2010 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 86D4F28C130 for ; Wed, 23 Jun 2010 09:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.707, 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 jdN1Eet0dHnL for ; Wed, 23 Jun 2010 09:35:29 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 79AB13A6AB5 for ; Wed, 23 Jun 2010 09:35:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,468,1272859200"; d="scan'208";a="22024937" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 23 Jun 2010 12:35:35 -0400 X-IronPort-AV: E=Sophos;i="4.53,468,1272859200"; d="scan'208";a="475273891" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jun 2010 12:35:00 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 23 Jun 2010 12:35:00 -0400 From: "WORLEY, Dale R (Dale)" To: "R.Jesske@telekom.de" , "john.elwell@siemens-enterprise.com" , "dispatch@ietf.org" Date: Wed, 23 Jun 2010 12:30:32 -0400 Thread-Topic: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKogA9AH9jABpml4wAGDoqZgABMLaQg= Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> , <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) 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, 23 Jun 2010 16:35:33 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of R.= Jesske@telekom.de [R.Jesske@telekom.de] Hi John, After reading this thread again, I would like to propose two requirements a= s follows: REQ-1: It should be possible to support PSTN-SIP-PSTN scenarios where the reason o= f a call release can be transferred though the SIP domain without any loss = of information and no change of reason. 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 3774028C13D for ; Wed, 23 Jun 2010 09:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.984 X-Spam-Level: X-Spam-Status: No, score=0.984 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJbO-qXXwArE for ; Wed, 23 Jun 2010 09:37:39 -0700 (PDT) Received: from blu0-omc4-s4.blu0.hotmail.com (blu0-omc4-s4.blu0.hotmail.com [65.55.111.143]) by core3.amsl.com (Postfix) with ESMTP id 274F63A6AAE for ; Wed, 23 Jun 2010 09:37:39 -0700 (PDT) Received: from BLU0-SMTP39 ([65.55.111.136]) by blu0-omc4-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 09:37:47 -0700 X-Originating-IP: [70.26.19.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.19.89]) by BLU0-SMTP39.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 09:37:46 -0700 Date: Wed, 23 Jun 2010 12:37:43 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2010 16:37:46.0926 (UTC) FILETIME=[695CB4E0:01CB12F2] Cc: dispatch@ietf.org Subject: Re: [dispatch] Reason In responses(draft-jesske-dispatch-reason-in-responses-02) 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, 23 Jun 2010 16:37:40 -0000 Query on REQ-3: are we talking about ISUP or ISDN release causes being forwarded from the PSTN? R.Jesske@telekom.de wrote: > Hi John, > After reading this thread again, I would like to propose two requirements as follows: > > REQ-1: > It should be possible to support PSTN-SIP-PSTN scenarios where the reason of a call release can be transferred though the SIP domain without any loss of information and no change of reason. > REQ-2: > It must be possible to provide an accurate indication to a UAC, so that the UAC can provide a suitable indication > to the user. > > > > As an additional Option there could be a third one as follows: > > REQ-3: > > UA may have the ability to display ISUP specific release causes or show a equivalent text. > > > Please indicate if you see this RE-3 within the scope or if it is already covered by REQ-2. > > Opinions. > > If people are happy I will provide an updated draft. > > Best Regards > > Roland > ... From md3135@att.com Wed Jun 23 13:20:57 2010 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 EAA4328C170 for ; Wed, 23 Jun 2010 13:20:56 -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 rkz-9rjSUKD0 for ; Wed, 23 Jun 2010 13:20:55 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 7B87328C103 for ; Wed, 23 Jun 2010 13:20:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1277324461!28975688!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24753 invoked from network); 23 Jun 2010 20:21:02 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Jun 2010 20:21:02 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o5NKKc8n002306; Wed, 23 Jun 2010 16:20:39 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o5NKKYWx002229; Wed, 23 Jun 2010 16:20:35 -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, 23 Jun 2010 16:20:56 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA06E52E85@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcsS8nRcbi3IJUZdS169fpkIaQapXwAHvSMQ References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> From: "DOLLY, MARTIN C (ATTLABS)" To: "Tom Taylor" , X-Mailman-Approved-At: Wed, 23 Jun 2010 14:39:22 -0700 Cc: dispatch@ietf.org Subject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) 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, 23 Jun 2010 20:20:57 -0000 ISUP, though there is an overlap with ISDN If from ISDN, then there is an interworking ISDN-->ISUP-->SIP -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Tom Taylor Sent: Wednesday, June 23, 2010 12:38 PM To: R.Jesske@telekom.de Cc: dispatch@ietf.org Subject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) Query on REQ-3: are we talking about ISUP or ISDN release causes being forwarded=20 from the PSTN? R.Jesske@telekom.de wrote: > Hi John, > After reading this thread again, I would like to propose two requirements as follows: >=20 > REQ-1: > It should be possible to support PSTN-SIP-PSTN scenarios where the reason of a call release can be transferred though the SIP domain without any loss of information and no change of reason.=20 > REQ-2: > It must be possible to provide an accurate indication to a UAC, so that the UAC can provide a suitable indication=20 > to the user. >=20 >=20 >=20 > As an additional Option there could be a third one as follows: >=20 > REQ-3: >=20 > UA may have the ability to display ISUP specific release causes or show a equivalent text.=20 >=20 >=20 > Please indicate if you see this RE-3 within the scope or if it is already covered by REQ-2. >=20 > Opinions.=20 >=20 > If people are happy I will provide an updated draft. >=20 > Best Regards >=20 > Roland >=20 ... _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Wed Jun 23 18:15:20 2010 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 E41B23A6AA0 for ; Wed, 23 Jun 2010 18:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.619, 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 uyvA71cgAUom for ; Wed, 23 Jun 2010 18:15:12 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E694A3A6A59 for ; Wed, 23 Jun 2010 18:15:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,470,1272859200"; d="scan'208";a="224624980" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Jun 2010 21:15:18 -0400 X-IronPort-AV: E=Sophos;i="4.53,470,1272859200"; d="scan'208";a="475407780" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jun 2010 21:15:18 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 23 Jun 2010 21:15:18 -0400 From: "WORLEY, Dale R (Dale)" To: "DOLLY, MARTIN C (ATTLABS)" , Tom Taylor , "R.Jesske@telekom.de" Date: Wed, 23 Jun 2010 21:13:18 -0400 Thread-Topic: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcsS8nRcbi3IJUZdS169fpkIaQapXwAHvSMQAApBNqM= Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> , <14C85D6CCBE92743AF33663BF5D24EBA06E52E85@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA06E52E85@gaalpa1msgusr7e.ugd.att.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: "dispatch@ietf.org" Subject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 01:15:20 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of DO= LLY, MARTIN C (ATTLABS) [md3135@att.com] ISUP, though there is an overlap with ISDN If from ISDN, then there is an interworking ISDN-->ISUP-->SIP _______________________________________________ One thing I haven't seen discussed is what is the meaning of carrying the I= SUP release code transparently if there is more than one variety of ISUP, i= f the same release code has different meanings in different PSTN networks. = In a perfect world, SIP would carry not only the ISUP release code, but so= me identification of the *system* of ISUP release codes that it was drawn f= rom. Dale From R.Jesske@telekom.de Thu Jun 24 00:44:14 2010 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 B01813A69DD for ; Thu, 24 Jun 2010 00:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 Ecmrpvti7LcY for ; Thu, 24 Jun 2010 00:44:13 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id D38C63A67F0 for ; Thu, 24 Jun 2010 00:44:12 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 24 Jun 2010 09:44:16 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 09:44:15 +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, 24 Jun 2010 09:44:15 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4063EB29F@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Reason Inresponses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKogA9AH9jABpml4wAGDoqZgABMLaQgAHkJ7oA== References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de><9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de><9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de>, <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> From: To: , , X-OriginalArrivalTime: 24 Jun 2010 07:44:15.0964 (UTC) FILETIME=[0BC149C0:01CB1371] Subject: Re: [dispatch] Reason Inresponses(draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 07:44:14 -0000 Hi Dale, Perhaps some more words, like that: REQ-2: It must be possible to provide an accurate indication to a UAC why the = call was released, so that the UAC can provide a suitable indication.=20 After discussion on this requirement the proposal was to keep it = generic. So now I tried to add some words to make is a little more = related to the kind of indication. As it looks like you would like to see the 3rd requirement in addition. = Correct? If yes then I changed the wording you provided to: REQ-3 :=20 A SIP UAC originating a dialog which terminates at a SIP-to-PSTN gateway = can determine the exact ISDN/ISUP Q.850 release code interworked by the = gateway or show an equivalent text. The Question then is how to express it that the SIP Dialog of course = terminates at the GW but the call itself is terminated within the = PSTN/ISDN network. And the cause is provided by the PSTN/ISDN network. = So that why I took the wording interworked by the gateway. Other views? Best Regards Roland Mit freundlichen Gr=FC=DFen Roland Jesske Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628-2766 (Tel.) +49 521 9210-3753 (Fax) +49 171 8618-445 (Mobil) E-Mail: r.jesske@telekom.de www.telekom.com =20 Erleben, was verbindet.=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht = jede E-Mail drucken. -----Urspr=FCngliche Nachricht----- Von: WORLEY, Dale R (Dale) [mailto:dworley@avaya.com]=20 Gesendet: Mittwoch, 23. Juni 2010 18:31 An: Jesske, Roland; john.elwell@siemens-enterprise.com; = dispatch@ietf.org Betreff: RE: [dispatch] Reason = Inresponses(draft-jesske-dispatch-reason-in-responses-02) ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of = R.Jesske@telekom.de [R.Jesske@telekom.de] Hi John, After reading this thread again, I would like to propose two = requirements as follows: REQ-1: It should be possible to support PSTN-SIP-PSTN scenarios where the = reason of a call release can be transferred though the SIP domain = without any loss of information and no change of reason. 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 D54F53A6807 for ; Thu, 24 Jun 2010 02:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.661, 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 Br9iSSO9fQgM for ; Thu, 24 Jun 2010 02:00:49 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 35EE93A6A40 for ; Thu, 24 Jun 2010 02:00:48 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-618257; Thu, 24 Jun 2010 11:00:56 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id C122923F0278; Thu, 24 Jun 2010 11:00:56 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 24 Jun 2010 11:00:56 +0200 From: "Elwell, John" To: "R.Jesske@telekom.de" , "dworley@avaya.com" , "dispatch@ietf.org" Date: Thu, 24 Jun 2010 11:00:55 +0200 Thread-Topic: [dispatch] Reason Inresponses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKogA9AH9jABpml4wAGDoqZgABMLaQgAHkJ7oAAEEj6A Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de><9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de><9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de>, <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD4063EB29F@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4063EB29F@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Reason Inresponses(draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 09:00:50 -0000 =20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: 24 June 2010 08:44 > To: dworley@avaya.com; Elwell, John; dispatch@ietf.org > Subject: AW: [dispatch] Reason=20 > Inresponses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Hi Dale, > Perhaps some more words, like that: >=20 > REQ-2: > It must be possible to provide an accurate indication to a=20 > UAC why the call was released, so that the UAC can provide a=20 > suitable indication.=20 >=20 > After discussion on this requirement the proposal was to keep=20 > it generic. So now I tried to add some words to make is a=20 > little more related to the kind of indication. >=20 > As it looks like you would like to see the 3rd requirement in=20 > addition. Correct? >=20 > If yes then I changed the wording you provided to: > REQ-3 :=20 > A SIP UAC originating a dialog which terminates at a=20 > SIP-to-PSTN gateway can determine the exact ISDN/ISUP Q.850=20 > release code interworked by the gateway or show an equivalent text. [JRE] The words " or show an equivalent text" are user-interface specific a= nd should be deleted. Determination of the Q.850 cause is sufficient - what= the UA then does with it (e.g., displays the cause number, displays text, = shows an icon, plays a tone or announcement) is outside the scope of SIP. I still have difficult determining the need for both REQ-2 and REQ-3. If we= have REQ-3, why do we need REQ-2. SIP already provides a means of satisfyi= ng REQ-2 through regular SIP response codes, since REQ-2 says nothing about= information from PSTN. If we talk about Q.850 causes in REQ-2, what would = be the difference between REQ-2 and REQ-3? John >=20 > The Question then is how to express it that the SIP Dialog of=20 > course terminates at the GW but the call itself is terminated=20 > within the PSTN/ISDN network. And the cause is provided by=20 > the PSTN/ISDN network. So that why I took the wording=20 > interworked by the gateway. >=20 > Other views? >=20 > Best Regards >=20 > Roland >=20 > Mit freundlichen Gr=FC=DFen > Roland Jesske >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > Roland Jesske > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628-2766 (Tel.) > +49 521 9210-3753 (Fax) > +49 171 8618-445 (Mobil) > E-Mail: r.jesske@telekom.de > www.telekom.com =20 >=20 > Erleben, was verbindet.=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 >=20 > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > nicht jede E-Mail drucken. >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: WORLEY, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Gesendet: Mittwoch, 23. Juni 2010 18:31 > An: Jesske, Roland; john.elwell@siemens-enterprise.com;=20 > dispatch@ietf.org > Betreff: RE: [dispatch] Reason=20 > Inresponses(draft-jesske-dispatch-reason-in-responses-02) >=20 > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org]=20 > On Behalf Of R.Jesske@telekom.de [R.Jesske@telekom.de] >=20 > Hi John, > After reading this thread again, I would like to propose two=20 > requirements as follows: >=20 > REQ-1: > It should be possible to support PSTN-SIP-PSTN scenarios=20 > where the reason of a call release can be transferred though=20 > the SIP domain without any loss of information and no change=20 > of reason.=20 > REQ-2: > It must be possible to provide an accurate indication to a=20 > UAC, so that the UAC can provide a suitable indication > to the user. >=20 > REQ-3: > UA may have the ability to display ISUP specific release=20 > causes or show a equivalent text. > _______________________________________________ >=20 > For REQ-1, I would rephrase it to be something like "where an=20 > ISUP release code can be transferred transparently through=20 > the SIP domain". Both "loss of information" and "no change=20 > of reason" are subject to interpretation -- what we're really=20 > hunting for is the ISUP release code (as a *number*) to go in=20 > one end and come out the other end unchanged. >=20 > As written REQ-2 is rather vague. What does "accurate" mean=20 > in this context? >=20 > I think what you mean by REQ-3 is "A SIP UAC originating a=20 > dialog which terminates at a SIP-to-PSTN gateway can=20 > determine the exact ISUP release code provided by the gateway." >=20 > Dale > = From R.Jesske@telekom.de Thu Jun 24 05:43:54 2010 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 05F313A68C2 for ; Thu, 24 Jun 2010 05:43:54 -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=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 nkttRxUNm1wx for ; Thu, 24 Jun 2010 05:43:52 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 782293A6851 for ; Thu, 24 Jun 2010 05:43:48 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 24 Jun 2010 14:43:47 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 14:43:38 +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, 24 Jun 2010 14:43:37 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4063EB5B8@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Reason Inresponses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcrW74P9CQ5oSJoRSc2LkHTNUkj5dwbUMKlQAAoty1ABCq4IQAAKTKogA9AH9jABpml4wAGDoqZgABMLaQgAHkJ7oAAEEj6AAAfljYA= References: <9886E5FCA6D76549A3011068483A4BD4060ADBCB@S4DE8PSAAQB.mitte.t-com.de><9886E5FCA6D76549A3011068483A4BD40610416B@S4DE8PSAAQB.mitte.t-com.de><9886E5FCA6D76549A3011068483A4BD40624CEDB@S4DE8PSAAQB.mitte.t-com.de>, <9886E5FCA6D76549A3011068483A4BD40639F8F6@S4DE8PSAAQB.mitte.t-com.de> <9886E5FCA6D76549A3011068483A4BD4063EB29F@S4DE8PSAAQB.mitte.t-com.de> From: To: , , X-OriginalArrivalTime: 24 Jun 2010 12:43:38.0495 (UTC) FILETIME=[DE4200F0:01CB139A] Subject: Re: [dispatch] Reason Inresponses(draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 12:43:54 -0000 Hi John, >From my side we can go with two requirements. Your comment is correct = and REQ-2 and 3 are overlapping. =20 Who would like to see in addition REQ-3 please indicate and Who not. I'm = waiting for your response. Thank you. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Gesendet: Donnerstag, 24. Juni 2010 11:01 An: Jesske, Roland; dworley@avaya.com; dispatch@ietf.org Betreff: RE: [dispatch] Reason = Inresponses(draft-jesske-dispatch-reason-in-responses-02) =20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: 24 June 2010 08:44 > To: dworley@avaya.com; Elwell, John; dispatch@ietf.org > Subject: AW: [dispatch] Reason=20 > Inresponses(draft-jesske-dispatch-reason-in-responses-02) >=20 > Hi Dale, > Perhaps some more words, like that: >=20 > REQ-2: > It must be possible to provide an accurate indication to a=20 > UAC why the call was released, so that the UAC can provide a=20 > suitable indication.=20 >=20 > After discussion on this requirement the proposal was to keep=20 > it generic. So now I tried to add some words to make is a=20 > little more related to the kind of indication. >=20 > As it looks like you would like to see the 3rd requirement in=20 > addition. Correct? >=20 > If yes then I changed the wording you provided to: > REQ-3 :=20 > A SIP UAC originating a dialog which terminates at a=20 > SIP-to-PSTN gateway can determine the exact ISDN/ISUP Q.850=20 > release code interworked by the gateway or show an equivalent text. [JRE] The words " or show an equivalent text" are user-interface = specific and should be deleted. Determination of the Q.850 cause is = sufficient - what the UA then does with it (e.g., displays the cause = number, displays text, shows an icon, plays a tone or announcement) is = outside the scope of SIP. I still have difficult determining the need for both REQ-2 and REQ-3. If = we have REQ-3, why do we need REQ-2. SIP already provides a means of = satisfying REQ-2 through regular SIP response codes, since REQ-2 says = nothing about information from PSTN. If we talk about Q.850 causes in = REQ-2, what would be the difference between REQ-2 and REQ-3? John >=20 > The Question then is how to express it that the SIP Dialog of=20 > course terminates at the GW but the call itself is terminated=20 > within the PSTN/ISDN network. And the cause is provided by=20 > the PSTN/ISDN network. So that why I took the wording=20 > interworked by the gateway. >=20 > Other views? >=20 > Best Regards >=20 > Roland >=20 > Mit freundlichen Gr=FC=DFen > Roland Jesske >=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > Roland Jesske > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628-2766 (Tel.) > +49 521 9210-3753 (Fax) > +49 171 8618-445 (Mobil) > E-Mail: r.jesske@telekom.de > www.telekom.com =20 >=20 > Erleben, was verbindet.=20 >=20 > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 >=20 > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und=20 > nicht jede E-Mail drucken. >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: WORLEY, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Gesendet: Mittwoch, 23. Juni 2010 18:31 > An: Jesske, Roland; john.elwell@siemens-enterprise.com;=20 > dispatch@ietf.org > Betreff: RE: [dispatch] Reason=20 > Inresponses(draft-jesske-dispatch-reason-in-responses-02) >=20 > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org]=20 > On Behalf Of R.Jesske@telekom.de [R.Jesske@telekom.de] >=20 > Hi John, > After reading this thread again, I would like to propose two=20 > requirements as follows: >=20 > REQ-1: > It should be possible to support PSTN-SIP-PSTN scenarios=20 > where the reason of a call release can be transferred though=20 > the SIP domain without any loss of information and no change=20 > of reason.=20 > REQ-2: > It must be possible to provide an accurate indication to a=20 > UAC, so that the UAC can provide a suitable indication > to the user. >=20 > REQ-3: > UA may have the ability to display ISUP specific release=20 > causes or show a equivalent text. > _______________________________________________ >=20 > For REQ-1, I would rephrase it to be something like "where an=20 > ISUP release code can be transferred transparently through=20 > the SIP domain". Both "loss of information" and "no change=20 > of reason" are subject to interpretation -- what we're really=20 > hunting for is the ISUP release code (as a *number*) to go in=20 > one end and come out the other end unchanged. >=20 > As written REQ-2 is rather vague. What does "accurate" mean=20 > in this context? >=20 > I think what you mean by REQ-3 is "A SIP UAC originating a=20 > dialog which terminates at a SIP-to-PSTN gateway can=20 > determine the exact ISUP release code provided by the gateway." >=20 > Dale >=20 From ian_elz@yahoo.co.uk Thu Jun 24 06:50:02 2010 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 B2F043A6942 for ; Thu, 24 Jun 2010 06:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 XTvj28xaNSHa for ; Thu, 24 Jun 2010 06:50:01 -0700 (PDT) Received: from n20.bullet.mail.ukl.yahoo.com (n20.bullet.mail.ukl.yahoo.com [87.248.110.137]) by core3.amsl.com (Postfix) with SMTP id AB09D3A694A for ; Thu, 24 Jun 2010 06:50:00 -0700 (PDT) Received: from [217.146.182.178] by n20.bullet.mail.ukl.yahoo.com with NNFMP; 24 Jun 2010 13:50:05 -0000 Received: from [87.248.111.146] by t4.bullet.ukl.yahoo.com with NNFMP; 24 Jun 2010 13:50:05 -0000 Received: from [127.0.0.1] by omp203.mail.ukl.yahoo.com with NNFMP; 24 Jun 2010 13:50:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 776161.82094.bm@omp203.mail.ukl.yahoo.com Received: (qmail 83311 invoked by uid 60001); 24 Jun 2010 13:50:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1277387405; bh=Gae7ds9hR6Oh2pF9FpA/2YY2lXYh5c3Ipv2dvm0jv7s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XDCAN6Gw2Y34hRJ+lNJrn1upfFsAYDlFsnYYuDw9NhkDCUHkLrScYwBxaJyBDHSL5dfEGGVXBBGLV+PYKRN8IIF85INKHfrNM8+aBKLY7wkVDdztjbpI7Uw3I6EusUJuaJMAAMWG+uGiwkCj9NCFGYZ4zoxtUyujAEhJHrcH2uM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=l1WEBj79ZfzMZjbaOT9RDYpl0CNs+KkNukVO0MwZ82ahanf5jcMbKl/S0X1FykNSiqlx9irQcd6PvzGszCzXfqJQjT1RKYg8ZIfw3Ef5JPCRxlX07hYqTyYrCESRr/zefKv7L87Zp5psYErQ5z0B/BEr5RqKFHhaK7rb/UbUvj8=; Message-ID: <576200.82617.qm@web29116.mail.ird.yahoo.com> X-YMail-OSG: 7Kxui0UVM1kmcbv.2yiwuk4hy_GYyBMC1kra3yqduJFmYuJ S77AEk3KtjdyoCjISgXpL56._mLf77S3QfT6IPPFGk769bZjB55LZdba.q4d OwVC4dmqQwAelJz4eqQoFHQ0AyjYukPryXSVxeDjUO_UICeMKR58XBtbLPC2 CwhgGsie6bfUxEYIkwwPqbNgOwUBHds.EFcv2.QNNE_wpYJkXjPYa63Um0vj siTd0RmRFDQ-- Received: from [194.237.142.6] by web29116.mail.ird.yahoo.com via HTTP; Thu, 24 Jun 2010 13:50:05 GMT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: Date: Thu, 24 Jun 2010 13:50:05 +0000 (GMT) From: Ian Elz To: dispatch@ietf.org, "WORLEY, Dale R \(Dale\)" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-651532606-1277387405=:82617" Cc: "DOLLY, MARTIN C \(ATTLABS\)" , "R.Jesske@telekom.de" Subject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 13:50:02 -0000 --0-651532606-1277387405=:82617 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dale,=0A=0AThe Q.850 cause values are standardised across the ISUP network.= As ISUP is used to interconnect the PSTN and PLMN worldwide the values are= universal.=0A=0AThe fact that the Reason header will indicate a protocol o= f "Q.850" =0A=0AThe only thing that is not considered in this draft is that= there may be 'location' and 'diagnostic' information associated the cause = values.=0A=0AThe Location indicates if the release cause comes from teh use= r, private networl, public network, transit network etc.=0A=0AThe Diagnosti= cs provides additional information as to why the realease occured and other= information which may be cause specific.=0A=0AThis additional information = is not usually used and I don't believe that it is the intention of this dr= aft to expand the Reason header to carry the additional information. Any in= formation which is required will need to be mapped by other mechanism betwe= en the ISUP and SIP networks, e.g. CCBS possible indicator.=0A=0AIan Elz=0A= =0A=0A=0AFrom: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] =0AOn = Behalf Of "WORLEY, Dale R (Dale)" =0A=0A=0A_____________= ___________________=0A From: dispatch-bounces@ietf.org [dispatch-bounces= @ietf.org] =0AOn Behalf Of DOLLY, MARTIN C (ATTLABS) [md3135@att.com]=0A=0A= ISUP, though there is an overlap with ISDN=0A=0A If from ISDN, then = there is an interworking ISDN-->ISUP-->SIP=0A______________________________= _________________=0A=0AOne thing I haven't seen discussed is what is the me= aning of carrying the =0AISUP release code transparently if there is more t= han one variety of =0AISUP, if the same release code has different meanings= in different PSTN =0Anetworks. In a perfect world, SIP would carry not on= ly the ISUP release code, but some identification of the *system* of ISUP r= elease codes =0Athat it was drawn from.=0A=0ADale=0A=0A=0A --0-651532606-1277387405=:82617 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dale,

The Q.850 cause values are standardised across the ISU= P network. As ISUP is used to interconnect the PSTN and PLMN worldwide the = values are universal.

The fact that the Reason header will indicate = a protocol of "Q.850"

The only thing that is not considered in this= draft is that there may be 'location' and 'diagnostic' information associa= ted the cause values.

The Location indicates if the release cause co= mes from teh user, private networl, public network, transit network etc.
The Diagnostics provides additional information as to why the realease= occured and other information which may be cause specific.

This add= itional information is not usually used and I don't believe that it is the = intention of this draft to expand the Reason header to carry the additional information. Any information which is required will need to be = mapped by other mechanism between the ISUP and SIP networks, e.g. CCBS poss= ible indicator.

Ian Elz


From: dispatch= -bounces@ietf.org [dispatch-bounces@ietf.org] =0AOn = Behalf Of "WORLEY, Dale R (Dale)" <dworley@avaya.com>
    From: dispatch-bounces= @ietf.org [dispatch-bounces@ietf.org] =0AOn Behalf O= f DOLLY, MARTIN C (ATTLABS) [md3135@att.com]

    ISUP,= =0A though there is an overlap with ISDN

    If from = ISDN, then there is=0A an interworking ISDN-->ISUP-->SIP
_________= ______________________________________

One=0A thing I haven't seen d= iscussed is what is the meaning of carrying the =0AISUP release code transp= arently if there is more than one variety of =0AISUP, if the same release c= ode has different meanings in different PSTN =0Anetworks.  In a perfec= t world, SIP would carry not only the ISUP release=0A code, but some identi= fication of the *system* of ISUP release codes =0Athat it was drawn from.
Dale
=0A

=0A=0A=0A=0A --0-651532606-1277387405=:82617-- From R.Jesske@telekom.de Thu Jun 24 06:57:54 2010 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 41A543A691B for ; Thu, 24 Jun 2010 06:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_FROM=2.3, 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 j9afc5MXhCH4 for ; Thu, 24 Jun 2010 06:57:47 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 1A1873A6816 for ; Thu, 24 Jun 2010 06:57:46 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 24 Jun 2010 15:57:49 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 15:57:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB13A5.3ADA5F74" Date: Thu, 24 Jun 2010 15:57:48 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4063EB640@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <576200.82617.qm@web29116.mail.ird.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcsTpCee5fc3T9dHTQalaTvf6nTMcAAAEIpQ References: <576200.82617.qm@web29116.mail.ird.yahoo.com> From: To: , , X-OriginalArrivalTime: 24 Jun 2010 13:57:49.0370 (UTC) FILETIME=[3B2FA1A0:01CB13A5] Cc: md3135@att.com Subject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 13:57:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB13A5.3ADA5F74 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ian, the location field for the Reason header was discussed in the past. But = it was decided not to include to many information. My impression is that = the location field is not used often for services or other network = feature. The only value would be for O&M reasons where more information = is given. So your analysis in the last sentence is correct. =20 This draft is not extending the Reason header it is only specifying the = use of the Reason Header within responses. =20 Best Regards =20 Roland Mit freundlichen Gr=FC=DFen=20 Roland Jesske=20 Deutsche Telekom Netzproduktion GmbH=20 Fixed Mobile Engineering Deutschland=20 Roland Jesske=20 Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 +49 6151 628-2766 (Tel.)=20 +49 521 9210-3753 (Fax)=20 +49 171 8618-445 (Mobil)=20 E-Mail: r.jesske@telekom.de =20 www.telekom.com =20 Erleben, was verbindet.=20 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr. DE 814645262=20 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht = jede E-Mail drucken.=20 =20 ________________________________ Von: Ian Elz [mailto:ian_elz@yahoo.co.uk]=20 Gesendet: Donnerstag, 24. Juni 2010 15:50 An: dispatch@ietf.org; WORLEY, Dale R (Dale) Cc: DOLLY, MARTIN C (ATTLABS); Tom Taylor; Jesske, Roland Betreff: Re: [dispatch] ReasonIn = responses(draft-jesske-dispatch-reason-in-responses-02) Dale, The Q.850 cause values are standardised across the ISUP network. As ISUP = is used to interconnect the PSTN and PLMN worldwide the values are = universal. The fact that the Reason header will indicate a protocol of "Q.850"=20 The only thing that is not considered in this draft is that there may be = 'location' and 'diagnostic' information associated the cause values. The Location indicates if the release cause comes from teh user, private = networl, public network, transit network etc. The Diagnostics provides additional information as to why the realease = occured and other information which may be cause specific. This additional information is not usually used and I don't believe that = it is the intention of this draft to expand the Reason header to carry = the additional information. Any information which is required will need = to be mapped by other mechanism between the ISUP and SIP networks, e.g. = CCBS possible indicator. Ian Elz From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of = "WORLEY, Dale R (Dale)" ________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On = Behalf Of DOLLY, MARTIN C (ATTLABS) [md3135@att.com] ISUP, though there is an overlap with ISDN If from ISDN, then there is an interworking ISDN-->ISUP-->SIP _______________________________________________ One thing I haven't seen discussed is what is the meaning of carrying = the ISUP release code transparently if there is more than one variety of = ISUP, if the same release code has different meanings in different PSTN = networks. In a perfect world, SIP would carry not only the ISUP release = code, but some identification of the *system* of ISUP release codes that = it was drawn from. Dale ------_=_NextPart_001_01CB13A5.3ADA5F74 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ian,
the location field for the Reason header was = discussed in=20 the past. But it was decided not to include to many information. My=20 impression is that the location field is not used often for = services or=20 other network feature. The only value would be for O&M reasons where = more=20 information is given. So your analysis in the last sentence is=20 correct.
 
This draft is not extending the Reason header = it is only=20 specifying the use of the Reason Header within = responses.
 
Best=20 Regards
 
Roland

Mit freundlichen=20 Grüßen
Roland=20 Jesske


Deutsche Telekom=20 Netzproduktion GmbH
Fixed Mobile Engineering = Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 = Darmstadt=20
+49 = 6151 628-2766=20 (Tel.)
+49 521 9210-3753  (Fax)
+49 171 8618-445  = (Mobil)=20
E-Mail:=20 r.jesske@telekom.de
www.telekom.com  =

Erleben, = was verbindet.=20

Deutsche = Telekom=20 Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn=20 (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn = (Vorsitzender), Albert=20 Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB = 14190=20
Sitz der = Gesellschaft:=20 Bonn
USt-IdNr. DE 814645262

Große Veränderungen=20 fangen klein an – Ressourcen schonen und nicht jede = E-Mail=20 drucken.

 

Von: Ian Elz = [mailto:ian_elz@yahoo.co.uk]=20
Gesendet: Donnerstag, 24. Juni 2010 15:50
An:=20 dispatch@ietf.org; WORLEY, Dale R (Dale)
Cc: DOLLY, MARTIN C=20 (ATTLABS); Tom Taylor; Jesske, Roland
Betreff: Re: [dispatch] = ReasonIn=20 responses(draft-jesske-dispatch-reason-in-responses-02)

Dale,

The Q.850 cause values are standardised across the = ISUP=20 network. As ISUP is used to interconnect the PSTN and PLMN worldwide the = values=20 are universal.

The fact that the Reason header will indicate a = protocol=20 of "Q.850"

The only thing that is not considered in this draft = is that=20 there may be 'location' and 'diagnostic' information associated the = cause=20 values.

The Location indicates if the release cause comes from = teh user,=20 private networl, public network, transit network etc.

The = Diagnostics=20 provides additional information as to why the realease occured and other = information which may be cause specific.

This additional = information is=20 not usually used and I don't believe that it is the intention of this = draft to=20 expand the Reason header to carry the additional information. Any = information=20 which is required will need to be mapped by other mechanism between the = ISUP and=20 SIP networks, e.g. CCBS possible indicator.

Ian Elz


From:=20 dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On=20 Behalf Of "WORLEY, Dale R (Dale)" <dworley@avaya.com>
    From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On=20 Behalf Of DOLLY, MARTIN C (ATTLABS) [md3135@att.com]

  =  =20 ISUP, though there is an overlap with ISDN

    If = from=20 ISDN, then there is an interworking=20 ISDN-->ISUP-->SIP
______________________________________________= _

One=20 thing I haven't seen discussed is what is the meaning of carrying the = ISUP=20 release code transparently if there is more than one variety of ISUP, if = the=20 same release code has different meanings in different PSTN = networks.  In a=20 perfect world, SIP would carry not only the ISUP release code, but some=20 identification of the *system* of ISUP release codes that it was drawn=20 from.

Dale

------_=_NextPart_001_01CB13A5.3ADA5F74-- From jim.calme@alcatel-lucent.com Thu Jun 24 07:31:20 2010 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 CE07B3A6957 for ; Thu, 24 Jun 2010 07:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubkiEC6WKD6R for ; Thu, 24 Jun 2010 07:30:38 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 8C09D3A67C1 for ; Thu, 24 Jun 2010 07:30:34 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o5OEUYtP028606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Jun 2010 09:30:34 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o5OEUHla012393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 24 Jun 2010 09:30:34 -0500 Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 24 Jun 2010 09:30:33 -0500 From: "Calme, James A (Jim)" To: Ian Elz , "dispatch@ietf.org" , "WORLEY, Dale R (Dale)" Date: Thu, 24 Jun 2010 09:30:32 -0500 Thread-Topic: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AcsTpC8sIA2D5aw6TBy2V6Cx9EmPfgAA5q/g Message-ID: References: <576200.82617.qm@web29116.mail.ird.yahoo.com> In-Reply-To: <576200.82617.qm@web29116.mail.ird.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DE08556E79FD1649AEE892A8C353EF611346AC980BUSNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "DOLLY, MARTIN C \(ATTLABS\)" , "R.Jesske@telekom.de" Subject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 14:31:21 -0000 --_000_DE08556E79FD1649AEE892A8C353EF611346AC980BUSNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ian, It is not true that cause values are "universal". I can agree that Q.850 is= the starting point, but there are many countries that define their own nat= ional extensions. Just consider the US network as one example. The US ANSI ISUP standard T1.1= 13 defines a number of cause values in addition to Q.850. In some cases the= values overlap with Q.850 definitions and in other cases they are making u= se of unused values. For the ANSI specific values the Cause Indicator codin= g standards is set to 10 to indicate that the value is based on a national = standard. Both Q.850 and ANSI-specific values are used within US networks. With this is mind, where RFC 3326 defines the protocol as protocol =3D "SIP" / "Q.850" / token for US networks the value "ANSI" is introduced as a token value. So there are networks where Reason header protocol values other than just "= Q.850" are being used to represent ISUP cause values. Regards, Jim ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Ian Elz Sent: Thursday, June 24, 2010 8:50 AM To: dispatch@ietf.org; WORLEY, Dale R (Dale) Cc: DOLLY, MARTIN C (ATTLABS); R.Jesske@telekom.de Subject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-= responses-02) Dale, The Q.850 cause values are standardised across the ISUP network. As ISUP is= used to interconnect the PSTN and PLMN worldwide the values are universal. The fact that the Reason header will indicate a protocol of "Q.850" The only thing that is not considered in this draft is that there may be 'l= ocation' and 'diagnostic' information associated the cause values. The Location indicates if the release cause comes from teh user, private ne= tworl, public network, transit network etc. The Diagnostics provides additional information as to why the realease occu= red and other information which may be cause specific. This additional information is not usually used and I don't believe that it= is the intention of this draft to expand the Reason header to carry the ad= ditional information. Any information which is required will need to be map= ped by other mechanism between the ISUP and SIP networks, e.g. CCBS possibl= e indicator. Ian Elz From: dispatch-bounces@ietf.org [dispatch= -bounces@ietf.org] On Behalf Of "WORLEY, = Dale R (Dale)" ________________________________ From: dispatch-bounces@ietf.org [disp= atch-bounces@ietf.org] On Behalf Of DOLLY= , MARTIN C (ATTLABS) [md3135@att.com] ISUP, though there is an overlap with ISDN If from ISDN, then there is an interworking ISDN-->ISUP-->SIP _______________________________________________ One thing I haven't seen discussed is what is the meaning of carrying the I= SUP release code transparently if there is more than one variety of ISUP, i= f the same release code has different meanings in different PSTN networks. = In a perfect world, SIP would carry not only the ISUP release code, but so= me identification of the *system* of ISUP release codes that it was drawn f= rom. Dale --_000_DE08556E79FD1649AEE892A8C353EF611346AC980BUSNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ian,

 

It is not true that cause values are &= #8220;universal”. I can agree that Q.850 is the starting point, but there are many countries = that define their own national extensions.

 

Just consider the US netw= ork as one example. The US ANSI ISUP standard T1.113 defines a number of cause val= ues in addition to Q.850. In some cases the values overlap with Q.850 definitio= ns and in other cases they are making use of unused values. For the ANSI speci= fic values the Cause Indicator coding standards is set to 10 to indicate that t= he value is based on a national standard. Both Q.850 and ANSI-specific values = are used within US networks.

 

With this is mind, where RFC 3326 defi= nes the protocol as

protocol  &n= bsp;       =3D  "SIP" / "Q.850" / token

for US networks the value “ANSI&= #8221; is introduced as a token value.

 

So there are networks where Reason hea= der protocol values other than just “Q.850” are being used to represent ISUP cause values.

 

Regards,

Jim

 

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Ian Elz
Sent: Thursday, June 24, 201= 0 8:50 AM
To: dispatch@ietf.org; WORLE= Y, Dale R (Dale)
Cc: DOLLY, MARTIN C (ATTLABS); R.Jesske@telekom.de
Subject: Re: [dispatch] Reas= onIn responses(draft-jesske-dispatch-reason-in-responses-02)<= o:p>

 

Dale,

The Q.850 cause values are standardised across the ISUP network. As ISUP is used to interconnect the PSTN and PLMN worldwide the values are universal.<= br>
The fact that the Reason header will indicate a protocol of "Q.850&quo= t;

The only thing that is not considered in this draft is that there may be 'location' and 'diagnostic' information associated the cause values.

The Location indicates if the release cause comes from teh user, private networl, public network, transit network etc.

The Diagnostics provides additional information as to why the realease occu= red and other information which may be cause specific.

This additional information is not usually used and I don't believe that it= is the intention of this draft to expand the Reason header to carry the additi= onal information. Any information which is required will need to be mapped by ot= her mechanism between the ISUP and SIP networks, e.g. CCBS possible indicator.<= br>
Ian Elz



From: dispatch-bounces@ietf.org = [dispatch-bounces@ietf.org]= On Behalf Of "WORLEY, Dale R (Dale)" <dworley@avaya.com><= /o:p>

    From: dispatch-bounces@ietf.org = [dispatch-bounces@ietf.org]= On Behalf Of DOLLY, MARTIN C (ATT= LABS) [md3135@att= .com]

    ISUP, though there is an overlap with ISDN

    If from ISDN, then there is an interworking ISDN-->ISUP-->SIP
_______________________________________________

One thing I haven't seen discussed is what is the meaning of carrying the I= SUP release code transparently if there is more than one variety of ISUP, if th= e same release code has different meanings in different PSTN networks.  = In a perfect world, SIP would carry not only the ISUP release code, but some identification of the *system* of ISUP release codes that it was drawn from= .

Dale

 

--_000_DE08556E79FD1649AEE892A8C353EF611346AC980BUSNAVSXCHMBSA_-- From fluffy@cisco.com Thu Jun 24 14:28:29 2010 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 27DC828C0EF for ; Thu, 24 Jun 2010 14:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.014 X-Spam-Level: X-Spam-Status: No, score=-110.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 bLkOxWG2CnAQ for ; Thu, 24 Jun 2010 14:28:28 -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 2E8D43A69E3 for ; Thu, 24 Jun 2010 14:28:28 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIJqI0yrRN+K/2dsb2JhbACfOnGoDppHhSEEg14 X-IronPort-AV: E=Sophos;i="4.53,476,1272844800"; d="scan'208";a="549832140" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2010 21:28:36 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o5OLSaLb018554 for ; Thu, 24 Jun 2010 21:28:36 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1078) Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings Date: Thu, 24 Jun 2010 15:28:35 -0600 Content-Transfer-Encoding: 7bit Message-Id: <35B2776F-9225-4B70-9958-CCA0E46C6D1D@cisco.com> References: <20100624210254.4B46C3A68D5@core3.amsl.com> To: DISPATCH list X-Mailer: Apple Mail (2.1078) Subject: [dispatch] Tentative time for DISPATCH at IETF 78 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, 24 Jun 2010 21:28:29 -0000 Note this *may* change. > DISPATCH Session 1 (2 hours) > Tuesday, Morning Session I 0900-1130 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dworley@avaya.com Thu Jun 24 15:00:09 2010 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 2E11A3A68A7 for ; Thu, 24 Jun 2010 15:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, 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 M-mL-XiXLBSq for ; Thu, 24 Jun 2010 15:00:08 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id EE6B13A6A6A for ; Thu, 24 Jun 2010 15:00:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,476,1272859200"; d="scan'208";a="195125021" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jun 2010 18:00:14 -0400 X-IronPort-AV: E=Sophos;i="4.53,476,1272859200"; d="scan'208";a="475746541" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jun 2010 18:00:13 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 24 Jun 2010 18:00:13 -0400 From: "WORLEY, Dale R (Dale)" To: "R.Jesske@telekom.de" , "ian_elz@yahoo.co.uk" , "dispatch@ietf.org" Date: Thu, 24 Jun 2010 18:00:12 -0400 Thread-Topic: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AQHLE+ieGAFXmwaXN0WuwTJA0eTWMw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "md3135@att.com" Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 22:00:09 -0000 I think the situation can be clarified. The various forms of REQ-1 aren't = really requirements, as they are difficult to verify whether or not they ha= ve been fully satisfied. But they form very good statement of the *intenti= on* of the requirements. I propose changing it to a "preamble" to the requ= irements. REQ-2/REQ-3 aren't really distinct, but do need to be expanded w= ith a warning regarding that "variants" may need to be tagged. (The exact = problems can be addressed by knowlegable people when formulating the soluti= on.) And we need to state that an extension mechanism must be provided. (= Although the Reason header already has such a mechanism, so it won't be dif= ficult to solve that problem.) So I get this text: In SIP-to-PSTN gateway scenarios, it is desirable to provide the UAC with the specific call release reason provided by the PSTN. To support this: REQ: Provide in SIP responses a way to carry PSTN call release codes, along with indication of any context or variant identification needed to interpret the code unambiguously. REQ: Provide an extensibility mechanism so that further information about the call release can be specified. Dale From ian_elz@yahoo.co.uk Thu Jun 24 16:04:48 2010 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 ADD0E3A69D2 for ; Thu, 24 Jun 2010 16:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 PE9pyWJ3zUCy for ; Thu, 24 Jun 2010 16:04:47 -0700 (PDT) Received: from n28.bullet.mail.ukl.yahoo.com (n28.bullet.mail.ukl.yahoo.com [87.248.110.145]) by core3.amsl.com (Postfix) with SMTP id D44273A6867 for ; Thu, 24 Jun 2010 16:04:46 -0700 (PDT) Received: from [217.146.182.177] by n28.bullet.mail.ukl.yahoo.com with NNFMP; 24 Jun 2010 23:04:52 -0000 Received: from [87.248.110.116] by t3.bullet.ukl.yahoo.com with NNFMP; 24 Jun 2010 23:04:52 -0000 Received: from [127.0.0.1] by omp221.mail.ukl.yahoo.com with NNFMP; 24 Jun 2010 23:04:52 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 293050.5278.bm@omp221.mail.ukl.yahoo.com Received: (qmail 9951 invoked by uid 60001); 24 Jun 2010 23:04:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1277420691; bh=TG74egzgIT14upam8+4SqGURgSHGohP7gwTHg0NkdgU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0EPtwmZwW7DmRRfHptmwYfqIKwJRXIT0YjtTVHc2Z75eOyGoG3UL+Msw3xoGbiAI6wBZj98U2wVw3xDwnUodxbjzUvtG1uOhy43sAIagSQzVCWI8b116V5fTV2J5sWhJvu2/f3xH13xI9hIHQWY4w6jYvXaljJJiK4jBtVVysdA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ijvk0arGCuItu+O9/mu3kPYaReyL2B6++Zags34ke/6fdIcAk7Cs+CrLJWP1768zIYo++1vrlJiwrZcQDfdDz0DEvsfm6tBPmJ52XVI8L5XrMNT/f+ojLK3TyL/Av7WKzoyqfNTaulumoihJj3pVbcviXSb1Gy4QTy2LqjWg5qE=; Message-ID: <994758.8793.qm@web29110.mail.ird.yahoo.com> X-YMail-OSG: e7rKZ1IVM1k8mekX1Gh43Mcg6MXbYvWZ45rtjJX2poYjxvT dfZv2rPvABGr.R_ENQN7kL3F.krZvLQ1z7MQqLNXW.0jHb3vJ0epq1Ty4wbA Vq1itluq6rwrMCsxgx5qqOTnnIqJnj3X4oDibxOwLo43Y.TwtRR01tjDrPw8 vizOPjc5LHiRolg4ehjgZQibDqjFTTIyltY50rAHey.cYac4si.v8N22dqI6 M3boVodIICGRBIZjVvmndOBI- Received: from [86.20.66.247] by web29110.mail.ird.yahoo.com via HTTP; Thu, 24 Jun 2010 23:04:51 GMT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: <576200.82617.qm@web29116.mail.ird.yahoo.com> Date: Thu, 24 Jun 2010 23:04:51 +0000 (GMT) From: Ian Elz To: "Calme, James A \(Jim\)" , "dispatch@ietf.org" , "WORLEY, Dale R \(Dale\)" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1538935183-1277420691=:8793" Cc: "DOLLY, MARTIN C \(ATTLABS\)" , "R.Jesske@telekom.de" Subject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-responses-02) 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, 24 Jun 2010 23:04:48 -0000 --0-1538935183-1277420691=:8793 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jim,=0A=0A=0AI agree.=0A=0AThe protocol specifies meaning of the cause prov= ided. I should have quoted Q.850 as an example as it is the one specificall= y mentioned in RFC3326.=0A=0AAny other specified protocol will have its own= values.=0A=0AIt is up to the PSTN-SIP gateway to understand the specified = protocol and the mapping of the cause values for that protocol.=0A=0ACheers= =0A=0AIan=0A=0A=0A=0A=0A________________________________=0AFrom: "Calme, Ja= mes A (Jim)" =0ATo: Ian Elz ; "dispatch@ietf.org" ; "WORLEY, Dale R (Dale)" =0ACc: "DOLLY, MARTIN C (ATTLABS)" ; "R.Jess= ke@telekom.de" =0ASent: Thu, 24 June, 2010 15:30:32=0A= Subject: RE: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-= responses-02)=0A=0A =0AIan,=0A =0AIt is not true that cause values are =E2= =80=9Cuniversal=E2=80=9D.=0AI can agree that Q.850 is the starting point, b= ut there are many countries that=0Adefine their own national extensions.=0A= =0AJust consider the US network as=0Aone example. The US ANSI ISUP standar= d T1.113 defines a number of cause values=0Ain addition to Q.850. In some c= ases the values overlap with Q.850 definitions=0Aand in other cases they ar= e making use of unused values. For the ANSI specific=0Avalues the Cause Ind= icator coding standards is set to 10 to indicate that the=0Avalue is based = on a national standard. Both Q.850 and ANSI-specific values are=0Aused with= in US networks.=0A =0AWith this is mind, where RFC 3326 defines=0Athe proto= col as=0Aprotocol =0A=3D "SIP" / "Q.850" / token=0Afor US networks= the value =E2=80=9CANSI=E2=80=9D=0Ais introduced as a token value.=0A =0AS= o there are networks where Reason header protocol=0Avalues other than just = =E2=80=9CQ.850=E2=80=9D are being used to represent ISUP=0Acause values.=0A= =0ARegards,=0AJim=0A =0A =0A=0A________________________________=0A =0AFrom= :dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of = Ian Elz=0ASent: Thursday, June 24, 2010 8:50=0AAM=0ATo: dispatch@ietf.org; = WORLEY,=0ADale R (Dale)=0ACc: DOLLY, MARTIN C (ATTLABS); R.Jesske@telekom.d= e=0ASubject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason= -in-responses-02)=0A =0ADale,=0A=0AThe Q.850 cause values are standardised = across the ISUP network. As ISUP is=0Aused to interconnect the PSTN and PLM= N worldwide the values are universal.=0A=0AThe fact that the Reason header = will indicate a protocol of "Q.850" =0A=0AThe only thing that is not consid= ered in this draft is that there may be=0A'location' and 'diagnostic' infor= mation associated the cause values.=0A=0AThe Location indicates if the rele= ase cause comes from teh user, private=0Anetworl, public network, transit n= etwork etc.=0A=0AThe Diagnostics provides additional information as to why = the realease occured=0Aand other information which may be cause specific.= =0A=0AThis additional information is not usually used and I don't believe t= hat it is=0Athe intention of this draft to expand the Reason header to carr= y the additional=0Ainformation. Any information which is required will need= to be mapped by other=0Amechanism between the ISUP and SIP networks, e.g. = CCBS possible indicator.=0A=0AIan Elz=0A=0A=0AFrom: dispatch-bounces@ietf.o= rg [dispatch-bounces@ietf.org] On=0ABehalf Of "WORLEY, Dale R (Dale)" =0A=0A________________________________=0A =0A From: dispat= ch-bounces@ietf.org [dispatch-bounces@ietf.org] On=0ABehalf Of DOLLY, MARTI= N C (ATTLABS) [md3135@att.com]=0A=0A ISUP, though there is an overlap wi= th ISDN=0A=0A If from ISDN, then there is an interworking=0AISDN-->ISUP-= ->SIP=0A_______________________________________________=0A=0AOne thing I ha= ven't seen discussed is what is the meaning of carrying the ISUP=0Arelease = code transparently if there is more than one variety of ISUP, if the=0Asame= release code has different meanings in different PSTN networks. In a=0Ape= rfect world, SIP would carry not only the ISUP release code, but some=0Aide= ntification of the *system* of ISUP release codes that it was drawn from.= =0A=0ADale=0A=0A=0A --0-1538935183-1277420691=:8793 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Jim,

I agree.

The protocol specifies meaning of the cause provided. I should have = quoted Q.850 as an example as it is the one specifically mentioned in RFC33= 26.

Any other specified protocol will have its own= values.

It is up to the PSTN-SIP gateway to under= stand the specified protocol and the mapping of the cause values for that p= rotocol.

Cheers

Ian
=


From: "Calme, James A (Jim)" <jim.calme@alcatel-lucent.com>
To: Ian Elz <ian_elz@yahoo.co.uk>; "dispatch@ietf.org"= <dispatch@ietf.org>; "WORLEY, Dale R (Dale)" <dworley@avaya.com&g= t;
Cc: "DOLLY, MARTIN C= (ATTLABS)" <md3135@att.com>; "R.Jesske@telekom.de" <R.Jesske@tele= kom.de>
Sent: Thu, 2= 4 June, 2010 15:30:32
Subject: RE: [dispatch] ReasonIn responses(draft-jesske-dispatch-reason-in-r= esponses-02)

=0A=0A=0A =0A =0A=0A =0A=0A =0A=0A =0A=0A=0A=0A=0A=0A=0A=0A
=0A=0AIan,

=0A=0A

= =C2=A0

=0A=0A

It is not true that cause values are =E2=80=9Cuniversal=E2= =80=9D.=0AI can agree that Q.850 is the starting point, but there are many = countries that=0Adefine their own national extensions.

= =0A=0A

=C2=A0<= /SPAN>

=0A=0A

Just consider the=0A US network as=0Aone example. The US ANSI ISU= P standard T1.113 defines a number of cause values=0Ain addition to Q.850. = In some cases the values overlap with Q.850 definitions=0Aand in other case= s they are making use of unused values. For the ANSI specific=0Avalues the = Cause Indicator coding standards is set to 10 to indicate that the=0Avalue = is based on a national standard. Both Q.850 and ANSI-specific values are=0A= used within US networks.

=0A=0A

=C2=A0

=0A=0A

With this is mind, w= here RFC 3326 defines=0Athe protocol as

=0A=0A

protocol=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=0A=3D=C2=A0 "SIP" / "Q.= 850" / token

=0A=0A

for US networks the value =E2=80=9CANSI=E2=80=9D=0Ai= s introduced as a token value.

=0A=0A

=C2=A0

=0A=0ASo there are net= works where Reason header protocol=0Avalues other than just =E2=80=9CQ.850= =E2=80=9D are being used to represent ISUP=0Acause values. =0A=0A

=C2= =A0

=0A=0A

Regards,

=0A=0A

Jim

=0A=0A

=C2=A0 =0A=0A

=C2= =A0

=0A=0A
=0A=0A
=0A=0A
=0A=0A
= =0A=0A

From:=0Adispatch-bounces@ietf.org= [mailto:dispatch-bounces@ietf.org] On= Behalf Of Ian Elz
=0ASe= nt: Thursday, June 24, 2010 8:50=0AAM
=0ATo: dispatch@ietf.org; WORLEY,=0ADale R (Dale)<= BR>=0ACc: DOLLY,=0A MARTIN = C (ATTLABS); R.Jesske@telekom.de
=0ASubject: Re: [dispatch] ReasonIn responses(draft-jesske-dispatc= h-reason-in-responses-02)

=0A=0A
=0A=0A

=C2=A0

=0A=0A=0A=0A
=0A=0A

Dale,
=0A
=0AThe Q.850 cause values are standardised across the IS= UP network. As ISUP is=0Aused to interconnect the PSTN and PLMN worldwide t= he values are universal.
=0A
=0AThe fact that the Reason header will = indicate a protocol of "Q.850"
=0A
=0AThe only thing that is not con= sidered in this draft is that there may be=0A'location' and 'diagnostic' in= formation associated the cause values.
=0A
=0AThe Location indicates = if the release cause comes from teh user, private=0Anetworl, public network= , transit network etc.
=0A
=0AThe Diagnostics provides additional inf= ormation as to why the realease occured=0Aand other information which may b= e cause specific.
=0A
=0AThis additional information is not usually u= sed and I don't believe that it is=0Athe intention of this draft to expand = the Reason header to carry the additional=0Ainformation. Any information wh= ich is required will need to be mapped by other=0Amechanism between the ISU= P and SIP networks, e.g. CCBS possible indicator.
=0A
=0AIan Elz

=0A=0A
=0A=0A
=0A=0A


=0A
=0AFrom: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On=0ABehalf Of = "WORLEY, Dale R (Dale)" <dworley@avaya.com>

=0A=0A<= DIV>=0A=0A
=0A=0A
=0A=0A
=0A=0A

=C2=A0=C2=A0=C2=A0 From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On=0ABeha= lf Of DOLLY, MARTIN C (ATTLABS) [md3135@att.com= ]
=0A
=0A=C2=A0=C2=A0=C2=A0 ISUP, though there is an overlap with= ISDN
=0A
=0A=C2=A0=C2=A0=C2=A0 If from ISDN, then there is an interw= orking=0AISDN-->ISUP-->SIP
=0A____________________________________= ___________
=0A
=0AOne thing I haven't seen discussed is what is the = meaning of carrying the ISUP=0Arelease code transparently if there is more = than one variety of ISUP, if the=0Asame release code has different meanings= in different PSTN networks.=C2=A0 In a=0Aperfect world, SIP would carry no= t only the ISUP release code, but some=0Aidentification of the *system* of = ISUP release codes that it was drawn from.
=0A
=0ADale<= /P> =0A=0A

=0A=0A
=0A=0A
=0A=0A

=C2=A0

=0A=0A
=0A=0A=0A=0A= =0A
=0A=0A=0A

=0A=0A=0A=0A --0-1538935183-1277420691=:8793-- From mary.ietf.barnes@gmail.com Mon Jun 28 10:38:23 2010 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 DB6BA3A6782 for ; Mon, 28 Jun 2010 10:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSuTE8-oDw0Y for ; Mon, 28 Jun 2010 10:38:22 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 83DCC28C129 for ; Mon, 28 Jun 2010 10:38:22 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id d26so96136eyd.51 for ; Mon, 28 Jun 2010 10:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=ZJlWxrgwPzleR1mN0LSZaqduCVN0z7jgMOxX665YqQY=; b=oyFjHXutw1mCvZaoMg8XB9TK7ZflSAws7LMhpKz08vkKWudZGYTPY5QZGNQ3pFK4np WhA2VN85YmQJT5HkdbQc+V05HiNINlI44/2wjaUBkRhIimK+aIyBgv3M+a/ZATU/TAsf EgoDWq1sX79MYSk7VY/rQ01PtPnRyvP8rvP78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=ASmwRQtQMVKNcC5iERMMS7+gvAM7DgMrCqANLeK1psBzXGCo1ecTJ88Do0zkw38xy8 w5B+7dsnC7X23PeRjGmErqlzBOPD99oSmXvJbIUUo2cP6ljFOZbxhpR0LYwZ8b0ZudLY adKNfzv6s0P57kMQ1v9pMnx+qlOaTGHIWnBCg= MIME-Version: 1.0 Received: by 10.213.31.141 with SMTP id y13mr1154636ebc.34.1277746708604; Mon, 28 Jun 2010 10:38:28 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Mon, 28 Jun 2010 10:38:28 -0700 (PDT) Date: Mon, 28 Jun 2010 12:38:28 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] VIPR - proposed charter version 3 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, 28 Jun 2010 17:38:24 -0000 Hi all, Below, please find version 3 of the VIPR proposed charter. It's been updated to reflect ML feedback, in particular VAP has been added and clarifications have been made with regards to impacts (i.e., none) on existing PSTN interfaces. Regards, Mary (DISPATCH WG co-chair) ============================================ VIPR Charter Proposal (Version 3) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users. The goal of this working group is to enable inter-domain communications over the the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will address this problem by developing a peer to peer based approach to finding domains that claim to be responsible for a given phone number and validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. The validation mechanism requires a domain to gather and maintain information related to PSTN calls. This information is used by call agents such as phones, SBCs and IP PBXs to route calls. The WG will define a client-server protocol between these call agents and the entity within a domain that maintains the information. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP messages are coming from a validated phone number. A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call. The working group will define new SIP headers and option tags, as necessary, to enable this. The essential characteristic of VIPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The solution set defined by this WG will be incrementally deployable using only existing interfaces to the PSTN. No changes will be required to existing PSTN capabilities, no new database access is needed nor is any new support from PSTN service providers required. The problem statement and some possible starting points for solutions are further discussed in the following internet drafts which shall form the bases of the WG documents: draft-rosenberg-dispatch-vipr-overview draft-rosenberg-dispatch-vipr-reload-usage draft-rosenberg-dispatch-vipr-pvp draft-rosenberg-dispatch-vipr-sip-antispam draft-rosenberg-dispatch-vipr-vap The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WGs such as sipcore and p2psip. From keith.drage@alcatel-lucent.com Mon Jun 28 10:43:09 2010 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 0ABDA3A685F for ; Mon, 28 Jun 2010 10:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=-2.038, BAYES_50=0.001, 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 x7+tDgV7Nw02 for ; Mon, 28 Jun 2010 10:43:07 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 73C553A67B4 for ; Mon, 28 Jun 2010 10:43:06 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5SHhB3A012008 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Jun 2010 19:43:11 +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; Mon, 28 Jun 2010 19:43:11 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes , DISPATCH Date: Mon, 28 Jun 2010 19:43:05 +0200 Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsW6MF4A7Y5VylNRGS1GPl7P9iBdwAAGCwA 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.64 on 155.132.188.80 Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 28 Jun 2010 17:43:09 -0000 I have a major issue with including "which shall form the bases of the WG d= ocuments" into the charter. To me this is confusing the charter discussion = with the working group that might eventually result deciding what its deliv= erables, and their contents, shall be. regards Keith=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Monday, June 28, 2010 6:38 PM > To: DISPATCH > Subject: [dispatch] VIPR - proposed charter version 3 >=20 > Hi all, >=20 > Below, please find version 3 of the VIPR proposed charter.=20 > It's been updated to reflect ML feedback, in particular VAP=20 > has been added and clarifications have been made with regards=20 > to impacts (i.e., none) on existing PSTN interfaces. >=20 > Regards, > Mary > (DISPATCH WG co-chair) >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > VIPR Charter Proposal (Version 3) >=20 > WG Name: Verification Involving PSTN Reachability (VIPR) >=20 > There are two globally deployed address spaces for=20 > communications used by more than a billion people daily -=20 > phone numbers and DNS rooted address such as web servers and=20 > email addresses. The inter-domain signaling design of SIP is=20 > primarily designed for email style addresses yet a large=20 > percentage of SIP deployments mostly use phone numbers for=20 > identifying users. The goal of this working group is to=20 > enable inter-domain communications over the the Internet,=20 > using protocols such as SIP, while still allowing people to=20 > use phone numbers to identify the person with whom they wish=20 > to communicate. >=20 > The VIPR WG will address this problem by developing a peer to=20 > peer based approach to finding domains that claim to be=20 > responsible for a given phone number and validation protocols=20 > to ensure a reasonable likelihood that a given domain=20 > actually is responsible for the phone number. In this=20 > context, "responsible" means an administrative domain, which=20 > is at least one of the domains, to which a PSTN call to this=20 > phone number would be routed. Once the domain responsible for=20 > the phone number is found, existing protocols, such as SIP,=20 > can be used for inter-domain communications. >=20 > Some validation protocols may be based on knowledge gathered=20 > around a PSTN call; for example, the ability to prove a call=20 > was received over the PSTN based on start and stop times.=20 > Other validation schemes, such as examining fingerprints or=20 > watermarking of PSTN media to show that a domain received a=20 > particular PSTN phone call, may also be considered by the=20 > working group. This validation will be accomplished using=20 > publicly available open interfaces to the PSTN, so the=20 > validation can be performed by any domain wishing to=20 > participate. The WG will select and standardize at least one=20 > validation scheme. >=20 > The validation mechanism requires a domain to gather and=20 > maintain information related to PSTN calls. This information=20 > is used by call agents such as phones, SBCs and IP PBXs to=20 > route calls. The WG will define a client-server protocol=20 > between these call agents and the entity within a domain that=20 > maintains the information. >=20 > To help mitigate SPAM issues when using SIP between domains,=20 > the WG will define a mechanism to enable one domain to check=20 > that incoming SIP messages are coming from a validated phone=20 > number. A phone number is considered validated if it is=20 > coming from a domain to which the calling domain had=20 > previously successfully placed a PSTN call. The working=20 > group will define new SIP headers and option tags, as=20 > necessary, to enable this. >=20 > The essential characteristic of VIPR is establishing=20 > authentication by PSTN reachability when it is not possible=20 > to use a direct reference to ENUM databases or other direct=20 > assertions of PSTN number ownership. Elements such as public=20 > ENUM easily coexist with VIPR but no direct interaction with=20 > ENUM will be required. The solution set defined by this WG=20 > will be incrementally deployable using only existing=20 > interfaces to the PSTN. No changes will be required to=20 > existing PSTN capabilities, no new database access is needed=20 > nor is any new support from PSTN service providers required. >=20 > The problem statement and some possible starting points for=20 > solutions are further discussed in the following internet=20 > drafts which shall form the bases of the WG documents: >=20 > draft-rosenberg-dispatch-vipr-overview > draft-rosenberg-dispatch-vipr-reload-usage > draft-rosenberg-dispatch-vipr-pvp > draft-rosenberg-dispatch-vipr-sip-antispam > draft-rosenberg-dispatch-vipr-vap >=20 > The working group will carefully coordinate with the security=20 > area, O&M area, as well as the appropriate RAI WGs such as=20 > sipcore and p2psip. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From mary.ietf.barnes@gmail.com Mon Jun 28 11:00:01 2010 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 41B2B3A6916 for ; Mon, 28 Jun 2010 11:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuxSup0quhY5 for ; Mon, 28 Jun 2010 11:00:00 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C0E6E3A67B1 for ; Mon, 28 Jun 2010 10:59:59 -0700 (PDT) Received: by ewy22 with SMTP id 22so284189ewy.31 for ; Mon, 28 Jun 2010 11:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9amVmEbVAzrR7m8E1tIzHdmDNWCbRpE8ooaPArXXMX0=; b=fnbgMM4hfY3jWYAjbdR9iLXeP6JlSRw3R8THEesTuYskZbLNHJyoW/9E/GBWT4cE5B vpIhus853cnvlZ9VZmCncSOlwnxroLG8kgDGVxQWSY6naVJ4of7sbXThmFKQmvqua2Qj TxZ4aJ6UkWL5BYwcV6GcqRoZOADTbGTc7wL80= 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:content-transfer-encoding; b=Tu1tCNn2jVautZFeXp7hEwrZVjaZauoQV40bk4OOBHPXlIolbme0+kWAD7FJIGNqwh ToJRZyYoJpjgso1wJgQno+aMDcHL774aOxdvfFvWRpelm7rdGc5WN/m1eJ4tfBZs/Amo e/gNaFMO6kn7JV778qziE8iUxLS+rSsvHMZJY= MIME-Version: 1.0 Received: by 10.213.20.132 with SMTP id f4mr1897884ebb.33.1277748006430; Mon, 28 Jun 2010 11:00:06 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Mon, 28 Jun 2010 11:00:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Jun 2010 13:00:06 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 28 Jun 2010 18:00:01 -0000 Hi Keith, That's a valid concern and we can rewrite the deliverables as functional descriptions as we have done for other WG charters even in cases where documents existed (e.g., overload). The current text is trying to say that these documents map to deliverables and can be used as WG documents, although as it notes these should be considered starting points (i.e., it's understood the proposed WG has change control), but certainly the current text is somewhat misleading. Thanks, Mary. On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith) wrote: > I have a major issue with including "which shall form the bases of the WG= documents" into the charter. To me this is confusing the charter discussio= n with the working group that might eventually result deciding what its del= iverables, and their contents, shall be. > > regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> Sent: Monday, June 28, 2010 6:38 PM >> To: DISPATCH >> Subject: [dispatch] VIPR - proposed charter version 3 >> >> Hi all, >> >> Below, please find version 3 of the VIPR proposed charter. >> It's been updated to reflect ML feedback, in particular VAP >> has been added and clarifications have been made with regards >> to impacts (i.e., none) on existing PSTN interfaces. >> >> Regards, >> Mary >> (DISPATCH WG co-chair) >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> VIPR Charter Proposal (Version 3) >> >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) >> >> There are two globally deployed address spaces for >> communications used by more than a billion people daily - >> phone numbers and DNS rooted address such as web servers and >> email addresses. The inter-domain signaling design of SIP is >> primarily designed for email style addresses yet a large >> percentage of SIP deployments mostly use phone numbers for >> identifying users. The goal of this working group is to >> enable inter-domain communications over the the Internet, >> using protocols such as SIP, while still allowing people to >> use phone numbers to identify the person with whom they wish >> to communicate. >> >> The VIPR WG will address this problem by developing a peer to >> peer based approach to finding domains that claim to be >> responsible for a given phone number and validation protocols >> to ensure a reasonable likelihood that a given domain >> actually is responsible for the phone number. In this >> context, "responsible" means an administrative domain, which >> is at least one of the domains, to which a PSTN call to this >> phone number would be routed. Once the domain responsible for >> the phone number is found, existing protocols, such as SIP, >> can be used for inter-domain communications. >> >> Some validation protocols may be based on knowledge gathered >> around a PSTN call; for example, the ability to prove a call >> was received over the PSTN based on start and stop times. >> Other validation schemes, such as examining fingerprints or >> watermarking of PSTN media to show that a domain received a >> particular PSTN phone call, may also be considered by the >> working group. This validation will be accomplished using >> publicly available open interfaces to the PSTN, so the >> validation can be performed by any domain wishing to >> participate. =A0The WG will select and standardize at least one >> validation scheme. >> >> The validation mechanism requires a domain to gather and >> maintain information related to PSTN calls. =A0This information >> is used by call agents such as phones, SBCs and IP PBXs to >> route calls. =A0The WG will define a client-server protocol >> between these call agents and the entity within a domain that >> maintains the information. >> >> To help mitigate SPAM issues when using SIP between domains, >> the WG will define a mechanism to enable one domain to check >> that incoming SIP messages are coming from a validated phone >> number. =A0A phone number is considered validated if it is >> coming from a domain to which the calling domain had >> previously successfully placed a PSTN call. =A0The working >> group will define new SIP headers and option tags, as >> necessary, to enable this. >> >> The essential characteristic of VIPR is establishing >> authentication by PSTN reachability when it is not possible >> to use a direct reference to ENUM databases or other direct >> assertions of PSTN number ownership. Elements such as public >> ENUM easily coexist with VIPR but no direct interaction with >> ENUM will be required. =A0The solution set defined by this WG >> will be incrementally deployable using only existing >> interfaces to the PSTN. =A0No changes will be required to >> existing PSTN capabilities, no new database access is needed >> nor is any new support from PSTN service providers required. >> >> The problem statement and some possible starting points for >> solutions are further discussed in the following internet >> drafts which shall form the bases of the WG documents: >> >> draft-rosenberg-dispatch-vipr-overview >> draft-rosenberg-dispatch-vipr-reload-usage >> draft-rosenberg-dispatch-vipr-pvp >> draft-rosenberg-dispatch-vipr-sip-antispam >> draft-rosenberg-dispatch-vipr-vap >> >> The working group will carefully coordinate with the security >> area, O&M area, as well as the appropriate RAI WGs such as >> sipcore and p2psip. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From gonzalo.camarillo@ericsson.com Tue Jun 29 04:03:04 2010 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 2E96E3A6A61 for ; Tue, 29 Jun 2010 04:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.256 X-Spam-Level: X-Spam-Status: No, score=-103.256 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5TqwzYhbZQx for ; Tue, 29 Jun 2010 04:03:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0C8663A6A6E for ; Tue, 29 Jun 2010 04:03:00 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-5b-4c29d2ef5639 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 25.FE.19600.FE2D92C4; Tue, 29 Jun 2010 13:03:11 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 13:03:01 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 13:03:00 +0200 Message-ID: <4C29D2E4.5080203@ericsson.com> Date: Tue, 29 Jun 2010 14:03:00 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2010 11:03:01.0014 (UTC) FILETIME=[A3B44360:01CB177A] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 29 Jun 2010 11:03:04 -0000 Hi, FYI: note the discussion below on the IETF general list. Cheers, Gonzalo -------- Original Message -------- Subject: Re: WG Review: Call Control UUI for SIP (cuss) Date: Mon, 28 Jun 2010 20:24:23 +0200 From: Cullen Jennings To: iesg@ietf.org CC: IETF Discussion Mailing List As far as I can tell, the WG says they wants to transfer some information to achieve cross vendor interoperability. However, what I believe the charter is actually going to do is exactly the opposite of that. When you get your head around what this charter is proposing, it is going to form a more or less opaque container for transporting proprietary information in a SIP header. It's hard to imagine how this will help interoperability. If we wanted to have interoperability, the charter would say what information needs to be transferred and have the WG define a way to get it between systems in an operable way. What the charter for this WG actually says they are going to do is make a special container for transfer proprietary information. There's not even willing to say what that proprietary information is used for other than things ISDN UUI which is a non interoperable and fairly proprietary field in ISDN. Furthermore they have asserted that existing containers such as SIP-T or SIP bodies can't be used for reasons that are hard to describe. (I reject the idea that because the call might not involved the PSTN, it can't use SIP-T). I think the folks that want to do this should get a much clear explanation of how this results in interoperability and why exist approach such as SIP-T will not work before this is chartered. I do think there is a need to standardize some important call control information used in call centers and related places. However, the "we need a standard container to exchange secret information WG" is a bad idea and violates the sprit of the SIP change process not to mention the mission of the IETF. In summary, I'm in favor of figuring out what the problems are people hope to solve with this WG and figuring out a way to write interoperable standards to achieve that. However, I think this charter should be rejected by the IESG and sent back to the drawing board. The RAI area has things of higher priority items to work on than a SIP header for transfer proprietary data. On Jun 22, 2010, at 10:00 , IESG Secretary wrote: > A new IETF working group has been proposed in the Real-time Applications > and Infrastructure Area. The IESG has not made any determination as yet. > The following draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the IESG mailing > list (iesg@ietf.org) by Tuesday, June 29, 2010. > > Call Control UUI for SIP (cuss) > -------------------------------------------------- > Current Status: Proposed Working Group > > Last modified: 2010-06-21 > > Chair(s): > TBD > > Real-time Applications and Infrastructure Area Director(s): > Gonzalo Camarillo > Robert Sparks > > Real-time Applications and Infrastructure Area Advisor: > Gonzalo Camarillo > > Mailing Lists: TBD > > Description of Working Group: > > The Call Control UUI for SIP (CUSS) working group is chartered to > define a Session Initiation Protocol (SIP) mechanism for transporting > call-control related user-to-user information (UUI) between User > Agents. > > The mechanism developed in this working group is applicable in the > following situations: > > 1. The information is generated and consumed by an application using > SIP during session setup but the application is not necessarily > even SIP aware. > 2. The behavior of SIP entities that support it is not significantly > changed (as discussed in Section 4 of RFC 5727). > 3. Generally only the User Agent Client (UAC) and User Agent Server > (UAS) are interested in the information. > 4. The information is expected to survive retargeting, redirection, > and transfers. > 5. SIP elements may need to apply policy about passing and screening > the information. > 6. Multi-vendor interoperability is important. > > This mechanism is not applicable in the following situations: > > 1. The behavior of SIP entities that support it is significantly > changed (as discussed in Section 4 of RFC 5727). > 2. The information is generated and consumed at the SIP layer by SIP > elements. > 3. SIP elements besides the UAC and UAS might be interested in > consuming (beyond applying policy) the information. > 4. There are specific privacy issues involved with the information > being transported (e.g., geolocation or emergency-related > information). > > User data of the mechanism will be clearly marked with the > application, encoding, semantics, and content type, allowing policy to > be applied by UAs. The working group will define the information that > each application must specify to utilize the mechanism. This type of > application-specific information will be specified in standards-track > documents. > > One important application of this mechanism is interworking with the > ISDN User to User Information Service. This application defined by > ITU-T Q.931 is extensively deployed in the PSTN today supporting such > applications as contact centers, call centers, and automatic call > distributors (ACDs). A major barrier to the movement of these > applications to SIP is the lack of a standard mechanism to transport > this information in SIP. For interworking with ISDN, minimal > information about the content of the UUI is available to the PSTN-SIP > gateways. In this case only, the content will just indicate ISDN UUI > Service 1 interworking rather than the actual content. > > Call control UUI is user information conveyed between user agents > during call control operations. As a result, the information must be > conveyed with the INVITE transaction, and must survive proxy > retargeting, redirection, and transfers. The mechanism must utilize a > minimum of SIP extensions since it will need to be supported by many > simple SIP user agents such as PSTN gateways. The mechanism must > interwork with the existing ISDN service but should also be extensible > for use by other applications and non-ISDN protocols. > > Even though interworking with the PSTN is an important requirement, > call control UUI can be exchanged between native SIP clients that do > not have any ISUP support. Therefore, existing SIP-T > encapsulation-based approaches defined in RFC3372 do not meet the > requirements to transport this type of information. > > Mechanisms based on the SIP INFO method, RFC2976, will not be > considered by the working group since the UUI contents carry > information that must be conveyed during session setup at the user > agent - the information must be conveyed with the INVITE transaction. > The information 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. > > The group will produce: > > - A problem statement and requirements document for implementing a SIP > call control UUI mechanism > > - A specification of the SIP extension to best meet those requirements. > > Goals and Milestones > ==================== > > Sep 10 - Problem statement and requirements document to IESG > (Informational) > Mar 11 - SIP call control UUI specification to IESG (PS) > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From bruno.chatras@orange-ftgroup.com Tue Jun 29 05:02:24 2010 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 27FDA3A68E7 for ; Tue, 29 Jun 2010 05:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jyDiqZwqkBC for ; Tue, 29 Jun 2010 05:02:22 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 32CBC3A6990 for ; Tue, 29 Jun 2010 05:02:22 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B68BAA00600; Tue, 29 Jun 2010 14:02:29 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id C8B0EA00629; Tue, 29 Jun 2010 14:01:14 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 13:59:47 +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: Tue, 29 Jun 2010 13:59:46 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4C29D2E4.5080203@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcsXesCgHUdl0ZQxQkOp/VVdUG0BmwABIEEg References: <4C29D2E4.5080203@ericsson.com> From: To: , X-OriginalArrivalTime: 29 Jun 2010 11:59:47.0916 (UTC) FILETIME=[926040C0:01CB1782] Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 29 Jun 2010 12:02:24 -0000 Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 does state = that SIP-T does not come into play when there is no PSTN involved. At the end of clause 2 we can read the following: "4. IP origination - = IP termination: This is a case for pure SIP. SIP-T (either encapsulation = or translation of ISUP) does not come into play as there is no PSTN = interworking." Besides, SIP-T would require encapsulating a full ISUP message (e.g. = IAM) while we are interested in just one parameter of the message in the = context of CUSS. This would I believe be a more severe drawback if SIP-T = were used for this purpose. Bruno > -----Message d'origine----- > De : dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo > Envoy=E9 : mardi 29 juin 2010 13:03 > =C0 : DISPATCH > Objet : [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) >=20 > Hi, >=20 > FYI: note the discussion below on the IETF general list. >=20 > Cheers, >=20 > Gonzalo >=20 > -------- Original Message -------- > Subject: Re: WG Review: Call Control UUI for SIP (cuss) > Date: Mon, 28 Jun 2010 20:24:23 +0200 > From: Cullen Jennings > To: iesg@ietf.org > CC: IETF Discussion Mailing List >=20 >=20 > As far as I can tell, the WG says they wants to transfer some=20 > information to achieve cross vendor interoperability.=20 > However, what I believe the charter is actually going to do=20 > is exactly the opposite of that. When you get your head=20 > around what this charter is proposing, it is going to form a=20 > more or less opaque container for transporting proprietary=20 > information in a SIP header. It's hard to imagine how this=20 > will help interoperability. >=20 > If we wanted to have interoperability, the charter would say=20 > what information needs to be transferred and have the WG=20 > define a way to get it between systems in an operable way.=20 > What the charter for this WG actually says they are going to=20 > do is make a special container for transfer proprietary=20 > information. There's not even willing to say what that=20 > proprietary information is used for other than things ISDN=20 > UUI which is a non interoperable and fairly proprietary=20 > field in ISDN. > Furthermore they have asserted that existing containers such=20 > as SIP-T or SIP bodies can't be used for reasons that are=20 > hard to describe. (I reject the idea that because the call=20 > might not involved the PSTN, it can't use SIP-T). >=20 > I think the folks that want to do this should get a much=20 > clear explanation of how this results in interoperability and=20 > why exist approach such as SIP-T will not work before this is=20 > chartered. >=20 > I do think there is a need to standardize some important call=20 > control information used in call centers and related places.=20 > However, the "we need a standard container to exchange secret=20 > information WG" is a bad idea and violates the sprit of the=20 > SIP change process not to mention the mission of the IETF. >=20 > In summary, I'm in favor of figuring out what the problems=20 > are people hope to solve with this WG and figuring out a way=20 > to write interoperable standards to achieve that. However, I=20 > think this charter should be rejected by the IESG and sent=20 > back to the drawing board. The RAI area has things of higher=20 > priority items to work on than a SIP header for transfer=20 > proprietary data. >=20 >=20 >=20 > On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >=20 > > A new IETF working group has been proposed in the Real-time=20 > > Applications and Infrastructure Area. The IESG has not=20 > made any determination as yet. > > The following draft charter was submitted, and is provided for=20 > > informational purposes only. Please send your comments to the IESG=20 > > mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. > >=20 > > Call Control UUI for SIP (cuss) > > -------------------------------------------------- > > Current Status: Proposed Working Group > >=20 > > Last modified: 2010-06-21 > >=20 > > Chair(s): > > TBD > >=20 > > Real-time Applications and Infrastructure Area Director(s): > > Gonzalo Camarillo Robert Sparks=20 > > > >=20 > > Real-time Applications and Infrastructure Area Advisor: > > Gonzalo Camarillo > >=20 > > Mailing Lists: TBD > >=20 > > Description of Working Group: > >=20 > > The Call Control UUI for SIP (CUSS) working group is chartered to=20 > > define a Session Initiation Protocol (SIP) mechanism for=20 > transporting=20 > > call-control related user-to-user information (UUI) between User=20 > > Agents. > >=20 > > The mechanism developed in this working group is applicable in the=20 > > following situations: > >=20 > > 1. The information is generated and consumed by an application using > > SIP during session setup but the application is not necessarily > > even SIP aware. > > 2. The behavior of SIP entities that support it is not significantly > > changed (as discussed in Section 4 of RFC 5727). > > 3. Generally only the User Agent Client (UAC) and User Agent Server > > (UAS) are interested in the information. > > 4. The information is expected to survive retargeting, redirection, > > and transfers. > > 5. SIP elements may need to apply policy about passing and screening > > the information. > > 6. Multi-vendor interoperability is important. > >=20 > > This mechanism is not applicable in the following situations: > >=20 > > 1. The behavior of SIP entities that support it is significantly > > changed (as discussed in Section 4 of RFC 5727). > > 2. The information is generated and consumed at the SIP layer by SIP > > elements. > > 3. SIP elements besides the UAC and UAS might be interested in > > consuming (beyond applying policy) the information. > > 4. There are specific privacy issues involved with the information > > being transported (e.g., geolocation or emergency-related > > information). > >=20 > > User data of the mechanism will be clearly marked with the=20 > > application, encoding, semantics, and content type,=20 > allowing policy to=20 > > be applied by UAs. The working group will define the=20 > information that=20 > > each application must specify to utilize the mechanism.=20 > This type of=20 > > application-specific information will be specified in=20 > standards-track=20 > > documents. > >=20 > > One important application of this mechanism is interworking=20 > with the=20 > > ISDN User to User Information Service. This application defined by=20 > > ITU-T Q.931 is extensively deployed in the PSTN today=20 > supporting such=20 > > applications as contact centers, call centers, and automatic call=20 > > distributors (ACDs). A major barrier to the movement of these=20 > > applications to SIP is the lack of a standard mechanism to=20 > transport=20 > > this information in SIP. For interworking with ISDN, minimal=20 > > information about the content of the UUI is available to=20 > the PSTN-SIP=20 > > gateways. In this case only, the content will just=20 > indicate ISDN UUI=20 > > Service 1 interworking rather than the actual content. > >=20 > > Call control UUI is user information conveyed between user agents=20 > > during call control operations. As a result, the=20 > information must be=20 > > conveyed with the INVITE transaction, and must survive proxy=20 > > retargeting, redirection, and transfers. The mechanism=20 > must utilize a=20 > > minimum of SIP extensions since it will need to be=20 > supported by many=20 > > simple SIP user agents such as PSTN gateways. The mechanism must=20 > > interwork with the existing ISDN service but should also be=20 > extensible=20 > > for use by other applications and non-ISDN protocols. > >=20 > > Even though interworking with the PSTN is an important requirement,=20 > > call control UUI can be exchanged between native SIP=20 > clients that do=20 > > not have any ISUP support. Therefore, existing SIP-T=20 > > encapsulation-based approaches defined in RFC3372 do not meet the=20 > > requirements to transport this type of information. > >=20 > > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > > considered by the working group since the UUI contents carry=20 > > information that must be conveyed during session setup at the user=20 > > agent - the information must be conveyed with the INVITE=20 > transaction. > > The information must be passed with the session setup request=20 > > (INVITE), responses to that INVITE, or session termination requests. > > As a result, it is not possible to use INFO in these cases. > >=20 > > The group will produce: > >=20 > > - A problem statement and requirements document for=20 > implementing a SIP=20 > > call control UUI mechanism > >=20 > > - A specification of the SIP extension to best meet those=20 > requirements. > >=20 > > Goals and Milestones > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Sep 10 - Problem statement and requirements document to IESG > > (Informational) > > Mar 11 - SIP call control UUI specification to IESG (PS)=20 > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From gonzalo.camarillo@ericsson.com Tue Jun 29 05:54:32 2010 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 2B3773A6B93 for ; Tue, 29 Jun 2010 05:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.217 X-Spam-Level: X-Spam-Status: No, score=-103.217 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ0zSYquiOvo for ; Tue, 29 Jun 2010 05:54:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A60043A6AE1 for ; Tue, 29 Jun 2010 05:54:29 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-3e-4c29ed0f5109 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 49.DF.19600.F0DE92C4; Tue, 29 Jun 2010 14:54:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:54:39 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Jun 2010 14:38:43 +0200 Message-ID: <4C29E953.5020201@ericsson.com> Date: Tue, 29 Jun 2010 15:38:43 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "bruno.chatras@orange-ftgroup.com" References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 29 Jun 2010 12:38:43.0466 (UTC) FILETIME=[0278E6A0:01CB1788] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 29 Jun 2010 12:54:32 -0000 Hi, note that, at this point, these discussions should take place on the IETF general list. If we start having discussions on different lists, it is going to become very difficult to follow them (some people may not be subscribed to both DISPATCH and the IETF list). Thanks, Gonzalo On 29/06/2010 2:59 PM, bruno.chatras@orange-ftgroup.com wrote: > Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 does state that SIP-T does not come into play when there is no PSTN involved. > > At the end of clause 2 we can read the following: "4. IP origination - IP termination: This is a case for pure SIP. SIP-T (either encapsulation or translation of ISUP) does not come into play as there is no PSTN interworking." > > Besides, SIP-T would require encapsulating a full ISUP message (e.g. IAM) while we are interested in just one parameter of the message in the context of CUSS. This would I believe be a more severe drawback if SIP-T were used for this purpose. > > Bruno > > >> -----Message d'origine----- >> De : dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >> Envoyé : mardi 29 juin 2010 13:03 >> À : DISPATCH >> Objet : [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) >> >> Hi, >> >> FYI: note the discussion below on the IETF general list. >> >> Cheers, >> >> Gonzalo >> >> -------- Original Message -------- >> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >> Date: Mon, 28 Jun 2010 20:24:23 +0200 >> From: Cullen Jennings >> To: iesg@ietf.org >> CC: IETF Discussion Mailing List >> >> >> As far as I can tell, the WG says they wants to transfer some >> information to achieve cross vendor interoperability. >> However, what I believe the charter is actually going to do >> is exactly the opposite of that. When you get your head >> around what this charter is proposing, it is going to form a >> more or less opaque container for transporting proprietary >> information in a SIP header. It's hard to imagine how this >> will help interoperability. >> >> If we wanted to have interoperability, the charter would say >> what information needs to be transferred and have the WG >> define a way to get it between systems in an operable way. >> What the charter for this WG actually says they are going to >> do is make a special container for transfer proprietary >> information. There's not even willing to say what that >> proprietary information is used for other than things ISDN >> UUI which is a non interoperable and fairly proprietary >> field in ISDN. >> Furthermore they have asserted that existing containers such >> as SIP-T or SIP bodies can't be used for reasons that are >> hard to describe. (I reject the idea that because the call >> might not involved the PSTN, it can't use SIP-T). >> >> I think the folks that want to do this should get a much >> clear explanation of how this results in interoperability and >> why exist approach such as SIP-T will not work before this is >> chartered. >> >> I do think there is a need to standardize some important call >> control information used in call centers and related places. >> However, the "we need a standard container to exchange secret >> information WG" is a bad idea and violates the sprit of the >> SIP change process not to mention the mission of the IETF. >> >> In summary, I'm in favor of figuring out what the problems >> are people hope to solve with this WG and figuring out a way >> to write interoperable standards to achieve that. However, I >> think this charter should be rejected by the IESG and sent >> back to the drawing board. The RAI area has things of higher >> priority items to work on than a SIP header for transfer >> proprietary data. >> >> >> >> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >> >>> A new IETF working group has been proposed in the Real-time >>> Applications and Infrastructure Area. The IESG has not >> made any determination as yet. >>> The following draft charter was submitted, and is provided for >>> informational purposes only. Please send your comments to the IESG >>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>> >>> Call Control UUI for SIP (cuss) >>> -------------------------------------------------- >>> Current Status: Proposed Working Group >>> >>> Last modified: 2010-06-21 >>> >>> Chair(s): >>> TBD >>> >>> Real-time Applications and Infrastructure Area Director(s): >>> Gonzalo Camarillo Robert Sparks >>> >>> >>> Real-time Applications and Infrastructure Area Advisor: >>> Gonzalo Camarillo >>> >>> Mailing Lists: TBD >>> >>> Description of Working Group: >>> >>> The Call Control UUI for SIP (CUSS) working group is chartered to >>> define a Session Initiation Protocol (SIP) mechanism for >> transporting >>> call-control related user-to-user information (UUI) between User >>> Agents. >>> >>> The mechanism developed in this working group is applicable in the >>> following situations: >>> >>> 1. The information is generated and consumed by an application using >>> SIP during session setup but the application is not necessarily >>> even SIP aware. >>> 2. The behavior of SIP entities that support it is not significantly >>> changed (as discussed in Section 4 of RFC 5727). >>> 3. Generally only the User Agent Client (UAC) and User Agent Server >>> (UAS) are interested in the information. >>> 4. The information is expected to survive retargeting, redirection, >>> and transfers. >>> 5. SIP elements may need to apply policy about passing and screening >>> the information. >>> 6. Multi-vendor interoperability is important. >>> >>> This mechanism is not applicable in the following situations: >>> >>> 1. The behavior of SIP entities that support it is significantly >>> changed (as discussed in Section 4 of RFC 5727). >>> 2. The information is generated and consumed at the SIP layer by SIP >>> elements. >>> 3. SIP elements besides the UAC and UAS might be interested in >>> consuming (beyond applying policy) the information. >>> 4. There are specific privacy issues involved with the information >>> being transported (e.g., geolocation or emergency-related >>> information). >>> >>> User data of the mechanism will be clearly marked with the >>> application, encoding, semantics, and content type, >> allowing policy to >>> be applied by UAs. The working group will define the >> information that >>> each application must specify to utilize the mechanism. >> This type of >>> application-specific information will be specified in >> standards-track >>> documents. >>> >>> One important application of this mechanism is interworking >> with the >>> ISDN User to User Information Service. This application defined by >>> ITU-T Q.931 is extensively deployed in the PSTN today >> supporting such >>> applications as contact centers, call centers, and automatic call >>> distributors (ACDs). A major barrier to the movement of these >>> applications to SIP is the lack of a standard mechanism to >> transport >>> this information in SIP. For interworking with ISDN, minimal >>> information about the content of the UUI is available to >> the PSTN-SIP >>> gateways. In this case only, the content will just >> indicate ISDN UUI >>> Service 1 interworking rather than the actual content. >>> >>> Call control UUI is user information conveyed between user agents >>> during call control operations. As a result, the >> information must be >>> conveyed with the INVITE transaction, and must survive proxy >>> retargeting, redirection, and transfers. The mechanism >> must utilize a >>> minimum of SIP extensions since it will need to be >> supported by many >>> simple SIP user agents such as PSTN gateways. The mechanism must >>> interwork with the existing ISDN service but should also be >> extensible >>> for use by other applications and non-ISDN protocols. >>> >>> Even though interworking with the PSTN is an important requirement, >>> call control UUI can be exchanged between native SIP >> clients that do >>> not have any ISUP support. Therefore, existing SIP-T >>> encapsulation-based approaches defined in RFC3372 do not meet the >>> requirements to transport this type of information. >>> >>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>> considered by the working group since the UUI contents carry >>> information that must be conveyed during session setup at the user >>> agent - the information must be conveyed with the INVITE >> transaction. >>> The information 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. >>> >>> The group will produce: >>> >>> - A problem statement and requirements document for >> implementing a SIP >>> call control UUI mechanism >>> >>> - A specification of the SIP extension to best meet those >> requirements. >>> >>> Goals and Milestones >>> ==================== >>> >>> Sep 10 - Problem statement and requirements document to IESG >>> (Informational) >>> Mar 11 - SIP call control UUI specification to IESG (PS) >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From christer.holmberg@ericsson.com Tue Jun 29 06:09:47 2010 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 C32673A659A for ; Tue, 29 Jun 2010 06:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.44 X-Spam-Level: X-Spam-Status: No, score=-4.44 tagged_above=-999 required=5 tests=[AWL=2.159, 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 FtXemnSrCULl for ; Tue, 29 Jun 2010 06:09:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 13C6C3A6A1D for ; Tue, 29 Jun 2010 06:09:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-1a-4c29f0a31ae4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.EC.10125.3A0F92C4; Tue, 29 Jun 2010 15:09:56 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 29 Jun 2010 15:09:55 +0200 From: Christer Holmberg To: Mary Barnes , "DRAGE, Keith (Keith)" Date: Tue, 29 Jun 2010 15:09:53 +0200 Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsW6+DlHD2th+CFTGygc7lzODr5RQAnwhNQ 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 29 Jun 2010 13:09:47 -0000 Hi, The second paragraph says: "The VIPR WG will address this problem..."=20 What problem? The charter does say that the problem statement is described in the referen= ced drafts. But, shouldn't it be described in the charter? Now it seems tha= t we first have to adopt the drafts in order to agree what the problem is..= . I also agree with Keith's comment regarding the usage of "shall be based on= this and that draft" wording. Regards, Christer =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 28. kes=E4kuuta 2010 21:00 > To: DRAGE, Keith (Keith) > Cc: DISPATCH > Subject: Re: [dispatch] VIPR - proposed charter version 3 >=20 > Hi Keith, >=20 > That's a valid concern and we can rewrite the deliverables as=20 > functional descriptions as we have done for other WG charters=20 > even in cases where documents existed (e.g., overload). The=20 > current text is trying to say that these documents map to=20 > deliverables and can be used as WG documents, although as it=20 > notes these should be considered starting points (i.e., it's=20 > understood the proposed WG has change control), but certainly=20 > the current text is somewhat misleading. >=20 > Thanks, > Mary. >=20 > On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith)=20 > wrote: > > I have a major issue with including "which shall form the=20 > bases of the WG documents" into the charter. To me this is=20 > confusing the charter discussion with the working group that=20 > might eventually result deciding what its deliverables, and=20 > their contents, shall be. > > > > regards > > > > Keith > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 6:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > >> Hi all, > >> > >> Below, please find version 3 of the VIPR proposed charter. > >> It's been updated to reflect ML feedback, in particular=20 > VAP has been=20 > >> added and clarifications have been made with regards to impacts=20 > >> (i.e., none) on existing PSTN interfaces. > >> > >> Regards, > >> Mary > >> (DISPATCH WG co-chair) > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> VIPR Charter Proposal (Version 3) > >> > >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) > >> > >> There are two globally deployed address spaces for communications=20 > >> used by more than a billion people daily - phone numbers and DNS=20 > >> rooted address such as web servers and email addresses. The=20 > >> inter-domain signaling design of SIP is primarily designed=20 > for email=20 > >> style addresses yet a large percentage of SIP deployments=20 > mostly use=20 > >> phone numbers for identifying users. The goal of this=20 > working group=20 > >> is to enable inter-domain communications over the the=20 > Internet, using=20 > >> protocols such as SIP, while still allowing people to use phone=20 > >> numbers to identify the person with whom they wish to communicate. > >> > >> The VIPR WG will address this problem by developing a peer to peer=20 > >> based approach to finding domains that claim to be=20 > responsible for a=20 > >> given phone number and validation protocols to ensure a reasonable=20 > >> likelihood that a given domain actually is responsible for=20 > the phone=20 > >> number. In this context, "responsible" means an administrative=20 > >> domain, which is at least one of the domains, to which a=20 > PSTN call to=20 > >> this phone number would be routed. Once the domain responsible for=20 > >> the phone number is found, existing protocols, such as SIP, can be=20 > >> used for inter-domain communications. > >> > >> Some validation protocols may be based on knowledge=20 > gathered around a=20 > >> PSTN call; for example, the ability to prove a call was=20 > received over=20 > >> the PSTN based on start and stop times. > >> Other validation schemes, such as examining fingerprints or=20 > >> watermarking of PSTN media to show that a domain received a=20 > >> particular PSTN phone call, may also be considered by the working=20 > >> group. This validation will be accomplished using publicly=20 > available=20 > >> open interfaces to the PSTN, so the validation can be performed by=20 > >> any domain wishing to participate. =A0The WG will select and=20 > >> standardize at least one validation scheme. > >> > >> The validation mechanism requires a domain to gather and maintain=20 > >> information related to PSTN calls. =A0This information is=20 > used by call=20 > >> agents such as phones, SBCs and IP PBXs to route calls. =A0 The WG will=20 > >> define a client-server protocol between these call agents and the=20 > >> entity within a domain that maintains the information. > >> > >> To help mitigate SPAM issues when using SIP between=20 > domains, the WG=20 > >> will define a mechanism to enable one domain to check that=20 > incoming=20 > >> SIP messages are coming from a validated phone number. =A0A phone=20 > >> number is considered validated if it is coming from a=20 > domain to which=20 > >> the calling domain had previously successfully placed a=20 > PSTN call. =A0 > >> The working group will define new SIP headers and option tags, as=20 > >> necessary, to enable this. > >> > >> The essential characteristic of VIPR is establishing=20 > authentication=20 > >> by PSTN reachability when it is not possible to use a direct=20 > >> reference to ENUM databases or other direct assertions of=20 > PSTN number=20 > >> ownership. Elements such as public ENUM easily coexist=20 > with VIPR but=20 > >> no direct interaction with ENUM will be required. =A0The=20 > solution set=20 > >> defined by this WG will be incrementally deployable using only=20 > >> existing interfaces to the PSTN. =A0No changes will be required to=20 > >> existing PSTN capabilities, no new database access is=20 > needed nor is=20 > >> any new support from PSTN service providers required. > >> > >> The problem statement and some possible starting points=20 > for solutions=20 > >> are further discussed in the following internet drafts which shall=20 > >> form the bases of the WG documents: > >> > >> draft-rosenberg-dispatch-vipr-overview > >> draft-rosenberg-dispatch-vipr-reload-usage > >> draft-rosenberg-dispatch-vipr-pvp > >> draft-rosenberg-dispatch-vipr-sip-antispam > >> draft-rosenberg-dispatch-vipr-vap > >> > >> The working group will carefully coordinate with the=20 > security area,=20 > >> O&M area, as well as the appropriate RAI WGs such as sipcore and=20 > >> p2psip. > >> _______________________________________________ > >> 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 R.Jesske@telekom.de Tue Jun 29 06:26:49 2010 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 A3ADF3A6BA5 for ; Tue, 29 Jun 2010 06:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_50=0.001, HELO_EQ_DE=0.35, 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 oS8VSv4zT+hx for ; Tue, 29 Jun 2010 06:26:43 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 2DD793A6A35 for ; Tue, 29 Jun 2010 06:26:38 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 29 Jun 2010 15:26:44 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 15:26:44 +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: Tue, 29 Jun 2010 15:26:43 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4064480BB@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) Thread-Index: AQHLE+ieGAFXmwaXN0WuwTJA0eTWM5KY9OpA References: From: To: , , X-OriginalArrivalTime: 29 Jun 2010 13:26:44.0774 (UTC) FILETIME=[B7DD9C60:01CB178E] Cc: md3135@att.com Subject: Re: [dispatch] Reason In responses (draft-jesske-dispatch-reason-in-responses-02) 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, 29 Jun 2010 13:26:49 -0000 Hi all, For the next step I would lkie to know in which direction I should go. Dales approach or something other like the earlier proposals?=20 So I would like to try to provide a new draft the next days. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: WORLEY, Dale R (Dale) [mailto:dworley@avaya.com]=20 Gesendet: Freitag, 25. Juni 2010 00:00 An: Jesske, Roland; ian_elz@yahoo.co.uk; dispatch@ietf.org Cc: md3135@att.com; tom111.taylor@bell.net Betreff: RE: [dispatch] Reason In responses = (draft-jesske-dispatch-reason-in-responses-02) I think the situation can be clarified. The various forms of REQ-1 = aren't really requirements, as they are difficult to verify whether or = not they have been fully satisfied. But they form very good statement = of the *intention* of the requirements. I propose changing it to a = "preamble" to the requirements. REQ-2/REQ-3 aren't really distinct, but = do need to be expanded with a warning regarding that "variants" may need = to be tagged. (The exact problems can be addressed by knowlegable = people when formulating the solution.) And we need to state that an = extension mechanism must be provided. (Although the Reason header = already has such a mechanism, so it won't be difficult to solve that = problem.) So I get this text: In SIP-to-PSTN gateway scenarios, it is desirable to provide the UAC with the specific call release reason provided by the PSTN. To support this: REQ: Provide in SIP responses a way to carry PSTN call release codes, along with indication of any context or variant identification needed to interpret the code unambiguously. REQ: Provide an extensibility mechanism so that further information about the call release can be specified. Dale From pp3129@att.com Tue Jun 29 06:31:43 2010 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 276EA3A6BF9 for ; Tue, 29 Jun 2010 06:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 bl68C5C+SkEp for ; Tue, 29 Jun 2010 06:31:36 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id E17673A6BEE for ; Tue, 29 Jun 2010 06:30:55 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-9.tower-167.messagelabs.com!1277818259!17101591!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31027 invoked from network); 29 Jun 2010 13:31:00 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jun 2010 13:31:00 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o5TDUZsH005844 for ; Tue, 29 Jun 2010 09:30:36 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o5TDUXv5005807 for ; Tue, 29 Jun 2010 09:30:33 -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: Tue, 29 Jun 2010 09:30:55 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B0444E234@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsW6NFU+eTWbJCPRcqtITvdDN8FVgAphAkA References: From: "PFAUTZ, PENN L (ATTCORP)" To: "DISPATCH" Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 29 Jun 2010 13:31:43 -0000 I'd like to understand precisely what is meant by "A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call." More importantly, I think the WG should discuss what the criteria for validation should be.=20 =20 Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Monday, June 28, 2010 1:38 PM To: DISPATCH Subject: [dispatch] VIPR - proposed charter version 3 Hi all, Below, please find version 3 of the VIPR proposed charter. It's been updated to reflect ML feedback, in particular VAP has been added and clarifications have been made with regards to impacts (i.e., none) on existing PSTN interfaces. Regards, Mary (DISPATCH WG co-chair) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D VIPR Charter Proposal (Version 3) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users. The goal of this working group is to enable inter-domain communications over the the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will address this problem by developing a peer to peer based approach to finding domains that claim to be responsible for a given phone number and validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. The validation mechanism requires a domain to gather and maintain information related to PSTN calls. This information is used by call agents such as phones, SBCs and IP PBXs to route calls. The WG will define a client-server protocol between these call agents and the entity within a domain that maintains the information. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP messages are coming from a validated phone number. A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call. The working group will define new SIP headers and option tags, as necessary, to enable this. The essential characteristic of VIPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The solution set defined by this WG will be incrementally deployable using only existing interfaces to the PSTN. No changes will be required to existing PSTN capabilities, no new database access is needed nor is any new support from PSTN service providers required. The problem statement and some possible starting points for solutions are further discussed in the following internet drafts which shall form the bases of the WG documents: draft-rosenberg-dispatch-vipr-overview draft-rosenberg-dispatch-vipr-reload-usage draft-rosenberg-dispatch-vipr-pvp draft-rosenberg-dispatch-vipr-sip-antispam draft-rosenberg-dispatch-vipr-vap The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WGs such as sipcore and p2psip. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From keith.drage@alcatel-lucent.com Tue Jun 29 08:16:15 2010 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 112D53A6BAD for ; Tue, 29 Jun 2010 08:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[AWL=1.408, 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 iAGha4+SF8C5 for ; Tue, 29 Jun 2010 08:16:13 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id CC9303A6895 for ; Tue, 29 Jun 2010 08:16:12 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5TFFdmd020401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Jun 2010 17:16:17 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 29 Jun 2010 17:15:30 +0200 From: "DRAGE, Keith (Keith)" To: "bruno.chatras@orange-ftgroup.com" , "Gonzalo.Camarillo@ericsson.com" , "dispatch@ietf.org" Date: Tue, 29 Jun 2010 17:15:25 +0200 Thread-Topic: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcsXesCgHUdl0ZQxQkOp/VVdUG0BmwABIEEgAAdkg2A= Message-ID: References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 29 Jun 2010 15:16:15 -0000 The UUI information is NOT ISUP. It is a transparent envelope to the entire= ISDN, so it is not part of an ISDN protocol and therefore not part of an I= SUP protocol. When carried by ISUP the envelope is bundled up in another en= velope with other information that ISUP carries transparently. So I believe, and have said repeatedly in the past, that references to SIP-= T are irrelevant in this case. The problem we do have though is that are legacy usages of this information= . In particular applications in PBXs carry it between themselves in ISDN ca= ll establishment. The information itself is not standardised. If you want t= o migrate a PBX from DSS1 to SIP, then you have to take this information in= to account. The desire is not for a WG group to standardise this existing u= sage (which in my view would be a complete non-starter), but to allow the t= ransfer of the existing information when migrated to a SIP environment. The= information transferred does not form part of SIP, and should not be stand= ardised as part of SIP. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 > bruno.chatras@orange-ftgroup.com > Sent: Tuesday, June 29, 2010 1:00 PM > To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org > Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI=20 > for SIP (cuss) >=20 > Hum, I'm a bit surprised by the comment about SIP-T. RFC3372=20 > does state that SIP-T does not come into play when there is=20 > no PSTN involved. >=20 > At the end of clause 2 we can read the following: "4. IP=20 > origination - IP termination: This is a case for pure SIP.=20 > SIP-T (either encapsulation or translation of ISUP) does not=20 > come into play as there is no PSTN interworking." >=20 > Besides, SIP-T would require encapsulating a full ISUP=20 > message (e.g. IAM) while we are interested in just one=20 > parameter of the message in the context of CUSS. This would I=20 > believe be a more severe drawback if SIP-T were used for this purpose. >=20 > Bruno >=20 >=20 > > -----Message d'origine----- > > De : dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo=20 > > Envoy=E9 : mardi 29 juin 2010 13:03 =C0 : DISPATCH Objet :=20 > [dispatch] Fwd:=20 > > Re: WG Review: Call Control UUI for SIP (cuss) > >=20 > > Hi, > >=20 > > FYI: note the discussion below on the IETF general list. > >=20 > > Cheers, > >=20 > > Gonzalo > >=20 > > -------- Original Message -------- > > Subject: Re: WG Review: Call Control UUI for SIP (cuss) > > Date: Mon, 28 Jun 2010 20:24:23 +0200 > > From: Cullen Jennings > > To: iesg@ietf.org > > CC: IETF Discussion Mailing List > >=20 > >=20 > > As far as I can tell, the WG says they wants to transfer some=20 > > information to achieve cross vendor interoperability. > > However, what I believe the charter is actually going to do=20 > is exactly=20 > > the opposite of that. When you get your head around what=20 > this charter=20 > > is proposing, it is going to form a more or less opaque=20 > container for=20 > > transporting proprietary information in a SIP header. It's hard to=20 > > imagine how this will help interoperability. > >=20 > > If we wanted to have interoperability, the charter would say what=20 > > information needs to be transferred and have the WG define a way to=20 > > get it between systems in an operable way. > > What the charter for this WG actually says they are going to do is=20 > > make a special container for transfer proprietary information. =20 > > There's not even willing to say what that proprietary=20 > information is=20 > > used for other than things ISDN UUI which is a non=20 > interoperable and=20 > > fairly proprietary field in ISDN. > > Furthermore they have asserted that existing containers=20 > such as SIP-T=20 > > or SIP bodies can't be used for reasons that are hard to=20 > describe. (I=20 > > reject the idea that because the call might not involved=20 > the PSTN, it=20 > > can't use SIP-T). > >=20 > > I think the folks that want to do this should get a much clear=20 > > explanation of how this results in interoperability and why exist=20 > > approach such as SIP-T will not work before this is chartered. > >=20 > > I do think there is a need to standardize some important=20 > call control=20 > > information used in call centers and related places. > > However, the "we need a standard container to exchange secret=20 > > information WG" is a bad idea and violates the sprit of the=20 > SIP change=20 > > process not to mention the mission of the IETF. > >=20 > > In summary, I'm in favor of figuring out what the problems=20 > are people=20 > > hope to solve with this WG and figuring out a way to write=20 > > interoperable standards to achieve that. However, I think=20 > this charter=20 > > should be rejected by the IESG and sent back to the drawing=20 > board. The=20 > > RAI area has things of higher priority items to work on than a SIP=20 > > header for transfer proprietary data. > >=20 > >=20 > >=20 > > On Jun 22, 2010, at 10:00 , IESG Secretary wrote: > >=20 > > > A new IETF working group has been proposed in the Real-time=20 > > > Applications and Infrastructure Area. The IESG has not=20 > > made any determination as yet. > > > The following draft charter was submitted, and is provided for=20 > > > informational purposes only. Please send your comments to=20 > the IESG=20 > > > mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. > > >=20 > > > Call Control UUI for SIP (cuss) > > > -------------------------------------------------- > > > Current Status: Proposed Working Group > > >=20 > > > Last modified: 2010-06-21 > > >=20 > > > Chair(s): > > > TBD > > >=20 > > > Real-time Applications and Infrastructure Area Director(s): > > > Gonzalo Camarillo =20 > Robert Sparks=20 > > > > > >=20 > > > Real-time Applications and Infrastructure Area Advisor: > > > Gonzalo Camarillo > > >=20 > > > Mailing Lists: TBD > > >=20 > > > Description of Working Group: > > >=20 > > > The Call Control UUI for SIP (CUSS) working group is chartered to=20 > > > define a Session Initiation Protocol (SIP) mechanism for=20 > > transporting=20 > > > call-control related user-to-user information (UUI) between User=20 > > > Agents. > > >=20 > > > The mechanism developed in this working group is=20 > applicable in the=20 > > > following situations: > > >=20 > > > 1. The information is generated and consumed by an=20 > application using > > > SIP during session setup but the application is not necessarily > > > even SIP aware. > > > 2. The behavior of SIP entities that support it is not=20 > significantly > > > changed (as discussed in Section 4 of RFC 5727). > > > 3. Generally only the User Agent Client (UAC) and User=20 > Agent Server > > > (UAS) are interested in the information. > > > 4. The information is expected to survive retargeting,=20 > redirection, > > > and transfers. > > > 5. SIP elements may need to apply policy about passing=20 > and screening > > > the information. > > > 6. Multi-vendor interoperability is important. > > >=20 > > > This mechanism is not applicable in the following situations: > > >=20 > > > 1. The behavior of SIP entities that support it is significantly > > > changed (as discussed in Section 4 of RFC 5727). > > > 2. The information is generated and consumed at the SIP=20 > layer by SIP > > > elements. > > > 3. SIP elements besides the UAC and UAS might be interested in > > > consuming (beyond applying policy) the information. > > > 4. There are specific privacy issues involved with the information > > > being transported (e.g., geolocation or emergency-related > > > information). > > >=20 > > > User data of the mechanism will be clearly marked with the=20 > > > application, encoding, semantics, and content type,=20 > > allowing policy to=20 > > > be applied by UAs. The working group will define the=20 > > information that=20 > > > each application must specify to utilize the mechanism.=20 > > This type of=20 > > > application-specific information will be specified in=20 > > standards-track=20 > > > documents. > > >=20 > > > One important application of this mechanism is interworking=20 > > with the=20 > > > ISDN User to User Information Service. This application=20 > defined by=20 > > > ITU-T Q.931 is extensively deployed in the PSTN today=20 > > supporting such=20 > > > applications as contact centers, call centers, and automatic call=20 > > > distributors (ACDs). A major barrier to the movement of these=20 > > > applications to SIP is the lack of a standard mechanism to=20 > > transport=20 > > > this information in SIP. For interworking with ISDN, minimal=20 > > > information about the content of the UUI is available to=20 > > the PSTN-SIP=20 > > > gateways. In this case only, the content will just=20 > > indicate ISDN UUI=20 > > > Service 1 interworking rather than the actual content. > > >=20 > > > Call control UUI is user information conveyed between user agents=20 > > > during call control operations. As a result, the=20 > > information must be=20 > > > conveyed with the INVITE transaction, and must survive proxy=20 > > > retargeting, redirection, and transfers. The mechanism=20 > > must utilize a=20 > > > minimum of SIP extensions since it will need to be=20 > > supported by many=20 > > > simple SIP user agents such as PSTN gateways. The mechanism must=20 > > > interwork with the existing ISDN service but should also be=20 > > extensible=20 > > > for use by other applications and non-ISDN protocols. > > >=20 > > > Even though interworking with the PSTN is an important=20 > requirement,=20 > > > call control UUI can be exchanged between native SIP=20 > > clients that do=20 > > > not have any ISUP support. Therefore, existing SIP-T=20 > > > encapsulation-based approaches defined in RFC3372 do not meet the=20 > > > requirements to transport this type of information. > > >=20 > > > Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > > > considered by the working group since the UUI contents carry=20 > > > information that must be conveyed during session setup at=20 > the user=20 > > > agent - the information must be conveyed with the INVITE=20 > > transaction. > > > The information must be passed with the session setup request=20 > > > (INVITE), responses to that INVITE, or session=20 > termination requests. > > > As a result, it is not possible to use INFO in these cases. > > >=20 > > > The group will produce: > > >=20 > > > - A problem statement and requirements document for=20 > > implementing a SIP=20 > > > call control UUI mechanism > > >=20 > > > - A specification of the SIP extension to best meet those=20 > > requirements. > > >=20 > > > Goals and Milestones > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > Sep 10 - Problem statement and requirements document to IESG > > > (Informational) > > > Mar 11 - SIP call control UUI specification to IESG (PS)=20 > > > _______________________________________________ > > > IETF-Announce mailing list > > > IETF-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/ietf-announce > >=20 > >=20 > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >=20 > >=20 > >=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 mary.ietf.barnes@gmail.com Tue Jun 29 09:11:25 2010 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 9F6D13A6930 for ; Tue, 29 Jun 2010 09:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 um5fSItH-+ss for ; Tue, 29 Jun 2010 09:11:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3ACF23A6C0C for ; Tue, 29 Jun 2010 09:11:23 -0700 (PDT) Received: by iwn40 with SMTP id 40so1173110iwn.31 for ; Tue, 29 Jun 2010 09:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KDwe/EkzwB9FWRl3RhSpT6oGAxm9H83amFUxx5rhiHI=; b=Kd/p61j2QE4Ih2borreVaV22aRxqm60YekhtkSlQ19NuO+T8QeKY3TZSSr+sVbY+nm dtxGp2w8Qnllos3k8/meq9C+UvWJxcwJAIyYTk9ezPGHQcC/3MJuCi6rZgJPuiK4VQn5 F11IlDRQGLt0+9jbXJMJRDy+TOYuS9gcBZ0zs= 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:content-transfer-encoding; b=xYrmMPKI22FE2E+WVNP0bwovnRahS7RUzw/bDmO8cW4zcjupSOj76IMqi+4AGN45dU RMOP7mSuIzD0G7aPlGIqlN6CTjiyuO+uEUB4pV90MqnDsQlXnQbGjz/WpNaO2rGVToXg z/auHByo9wyNdL6oW7VKYBsErm5DhJt+e9M4Q= MIME-Version: 1.0 Received: by 10.231.124.41 with SMTP id s41mr7100491ibr.165.1277827893592; Tue, 29 Jun 2010 09:11:33 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Tue, 29 Jun 2010 09:11:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Jun 2010 11:11:33 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH , "DRAGE, Keith \(Keith\)" Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 29 Jun 2010 16:11:25 -0000 Hi Christer, "this problem" refers to that stated in the previous paragraph, which is stated fairly clearly. Would rewording the first sentence in the second paragraph to something like the following make it more clear to you? " The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number along with validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number." The intent is not at all that the drafts MUST be adopted in order to agree the problem statement. The charter should be standalone and as I responded to Keith, we can generalize the deliverables (to match the work items that are described in the body of the charter). Certainly, having such detailed documents at the outset can be misleading in terms of the intent of the WG, however, as with any documents that might be adopted or used as a starting point for the WG documents, change control belongs to the WG. We have lots of examples of similar situations (within RAI) that have resulted in a significantly different WG document (even as early as a -00) as compared to the individual document that was the starting point for the WG document. Thanks, Mary. On Tue, Jun 29, 2010 at 8:09 AM, Christer Holmberg wrote: > > Hi, > > The second paragraph says: "The VIPR WG will address this problem..." > > What problem? > > The charter does say that the problem statement is described in the refer= enced drafts. But, shouldn't it be described in the charter? Now it seems t= hat we first have to adopt the drafts in order to agree what the problem is= ... > > I also agree with Keith's comment regarding the usage of "shall be based = on this and that draft" wording. > > Regards, > > Christer > > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> Sent: 28. kes=E4kuuta 2010 21:00 >> To: DRAGE, Keith (Keith) >> Cc: DISPATCH >> Subject: Re: [dispatch] VIPR - proposed charter version 3 >> >> Hi Keith, >> >> That's a valid concern and we can rewrite the deliverables as >> functional descriptions as we have done for other WG charters >> even in cases where documents existed (e.g., overload). =A0The >> current text is trying to say that these documents map to >> deliverables and can be used as WG documents, although as it >> notes these should be considered starting points (i.e., it's >> understood the proposed WG has change control), but certainly >> the current text is somewhat misleading. >> >> Thanks, >> Mary. >> >> On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith) >> wrote: >> > I have a major issue with including "which shall form the >> bases of the WG documents" into the charter. To me this is >> confusing the charter discussion with the working group that >> might eventually result deciding what its deliverables, and >> their contents, shall be. >> > >> > regards >> > >> > Keith >> > >> >> -----Original Message----- >> >> From: dispatch-bounces@ietf.org >> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> >> Sent: Monday, June 28, 2010 6:38 PM >> >> To: DISPATCH >> >> Subject: [dispatch] VIPR - proposed charter version 3 >> >> >> >> Hi all, >> >> >> >> Below, please find version 3 of the VIPR proposed charter. >> >> It's been updated to reflect ML feedback, in particular >> VAP has been >> >> added and clarifications have been made with regards to impacts >> >> (i.e., none) on existing PSTN interfaces. >> >> >> >> Regards, >> >> Mary >> >> (DISPATCH WG co-chair) >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> VIPR Charter Proposal (Version 3) >> >> >> >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) >> >> >> >> There are two globally deployed address spaces for communications >> >> used by more than a billion people daily - phone numbers and DNS >> >> rooted address such as web servers and email addresses. The >> >> inter-domain signaling design of SIP is primarily designed >> for email >> >> style addresses yet a large percentage of SIP deployments >> mostly use >> >> phone numbers for identifying users. The goal of this >> working group >> >> is to enable inter-domain communications over the the >> Internet, using >> >> protocols such as SIP, while still allowing people to use phone >> >> numbers to identify the person with whom they wish to communicate. >> >> >> >> The VIPR WG will address this problem by developing a peer to peer >> >> based approach to finding domains that claim to be >> responsible for a >> >> given phone number and validation protocols to ensure a reasonable >> >> likelihood that a given domain actually is responsible for >> the phone >> >> number. In this context, "responsible" means an administrative >> >> domain, which is at least one of the domains, to which a >> PSTN call to >> >> this phone number would be routed. Once the domain responsible for >> >> the phone number is found, existing protocols, such as SIP, can be >> >> used for inter-domain communications. >> >> >> >> Some validation protocols may be based on knowledge >> gathered around a >> >> PSTN call; for example, the ability to prove a call was >> received over >> >> the PSTN based on start and stop times. >> >> Other validation schemes, such as examining fingerprints or >> >> watermarking of PSTN media to show that a domain received a >> >> particular PSTN phone call, may also be considered by the working >> >> group. This validation will be accomplished using publicly >> available >> >> open interfaces to the PSTN, so the validation can be performed by >> >> any domain wishing to participate. =A0The WG will select and >> >> standardize at least one validation scheme. >> >> >> >> The validation mechanism requires a domain to gather and maintain >> >> information related to PSTN calls. =A0This information is >> used by call >> >> agents such as phones, SBCs and IP PBXs to route calls. > The WG will >> >> define a client-server protocol between these call agents and the >> >> entity within a domain that maintains the information. >> >> >> >> To help mitigate SPAM issues when using SIP between >> domains, the WG >> >> will define a mechanism to enable one domain to check that >> incoming >> >> SIP messages are coming from a validated phone number. =A0A phone >> >> number is considered validated if it is coming from a >> domain to which >> >> the calling domain had previously successfully placed a >> PSTN call. >> >> The working group will define new SIP headers and option tags, as >> >> necessary, to enable this. >> >> >> >> The essential characteristic of VIPR is establishing >> authentication >> >> by PSTN reachability when it is not possible to use a direct >> >> reference to ENUM databases or other direct assertions of >> PSTN number >> >> ownership. Elements such as public ENUM easily coexist >> with VIPR but >> >> no direct interaction with ENUM will be required. =A0The >> solution set >> >> defined by this WG will be incrementally deployable using only >> >> existing interfaces to the PSTN. =A0No changes will be required to >> >> existing PSTN capabilities, no new database access is >> needed nor is >> >> any new support from PSTN service providers required. >> >> >> >> The problem statement and some possible starting points >> for solutions >> >> are further discussed in the following internet drafts which shall >> >> form the bases of the WG documents: >> >> >> >> draft-rosenberg-dispatch-vipr-overview >> >> draft-rosenberg-dispatch-vipr-reload-usage >> >> draft-rosenberg-dispatch-vipr-pvp >> >> draft-rosenberg-dispatch-vipr-sip-antispam >> >> draft-rosenberg-dispatch-vipr-vap >> >> >> >> The working group will carefully coordinate with the >> security area, >> >> O&M area, as well as the appropriate RAI WGs such as sipcore and >> >> p2psip. >> >> _______________________________________________ >> >> 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.ietf.barnes@gmail.com Tue Jun 29 09:17:28 2010 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 92F773A6C08 for ; Tue, 29 Jun 2010 09:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 BCr1s+CddS85 for ; Tue, 29 Jun 2010 09:17:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 16FC43A6A6C for ; Tue, 29 Jun 2010 09:17:27 -0700 (PDT) Received: by iwn40 with SMTP id 40so1178558iwn.31 for ; Tue, 29 Jun 2010 09:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3jTVqWxrVlMFNISUAXRXVYrJJQ2334LT3vNt+gr5Dz0=; b=YKwEgHpNd7LKbuji8lxK+BoB3zWgn3T3sC6GjkG/8kFPRMBGUUfsyTNP/ruRj00vKF 27R2hOOOZWUYVlNFlcj2AIATta+MxF+SLk8RtzIm0icFXiqPWtF/3D97rFoi5Q+mdlaD Bb0OWO5JjvZQQ0l7+/3TZqPFj5ygf/vSJJH/Q= 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:content-transfer-encoding; b=QRATpQlco/IzAp//0q5cMDHSs+g0nciH4yoAvLGdVj309KcZzgxNTjcs6eYFL1e1tr BGeXvD39zX41WKVqd2RgoTNZ73WxLiX5eZNEHnqxIGXBXsbZue7BvmN4SHfBlZU1yNMs jrLbxHyERCfJlaFz/FYAw+sQIuo7jdQWO2YU0= MIME-Version: 1.0 Received: by 10.231.14.2 with SMTP id e2mr1197084iba.155.1277828257334; Tue, 29 Jun 2010 09:17:37 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Tue, 29 Jun 2010 09:17:37 -0700 (PDT) In-Reply-To: <35FE871E2B085542A35726420E29DA6B0444E234@gaalpa1msgusr7a.ugd.att.com> References: <35FE871E2B085542A35726420E29DA6B0444E234@gaalpa1msgusr7a.ugd.att.com> Date: Tue, 29 Jun 2010 11:17:37 -0500 Message-ID: From: Mary Barnes To: "PFAUTZ, PENN L (ATTCORP)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 29 Jun 2010 16:17:28 -0000 Hi Penn, Absolutely, the WG would discuss the criteria for validation - the last sentence in the 3rd paragraph discusses this and notes: " The WG will select and standardize at least one validation scheme." The sentence you are asking about is in the SPAM section which is something that happens on top of the validation - i.e., if phone numbers associated with a specific domain have been validated, this validation criteria is applicable to other numbers from the same domain. Thanks, Mary. On Tue, Jun 29, 2010 at 8:30 AM, PFAUTZ, PENN L (ATTCORP) wrote: > I'd like to understand precisely what is meant by "A phone number is > considered validated if it is coming from a domain to which the calling > domain had previously successfully placed a PSTN call." > More importantly, I think the WG should discuss what the criteria for > validation should be. > > Penn Pfautz > AT&T Access Management > +1-732-420-4962 > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Monday, June 28, 2010 1:38 PM > To: DISPATCH > Subject: [dispatch] VIPR - proposed charter version 3 > > Hi all, > > Below, please find version 3 of the VIPR proposed charter. It's been > updated to reflect ML feedback, in particular VAP has been added and > clarifications have been made with regards to impacts (i.e., none) on > existing PSTN interfaces. > > Regards, > Mary > (DISPATCH WG co-chair) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > VIPR Charter Proposal (Version 3) > > WG Name: =A0Verification Involving PSTN Reachability (VIPR) > > There are two globally deployed address spaces for communications used > by more than a billion people daily - phone numbers and DNS rooted > address such as web servers and email addresses. The inter-domain > signaling design of SIP is primarily designed for email style addresses > yet a large percentage of SIP deployments mostly use phone numbers for > identifying users. The goal of this working group is to enable > inter-domain communications over the the Internet, using protocols such > as SIP, while still allowing people to use phone numbers to identify the > person with whom they wish to communicate. > > The VIPR WG will address this problem by developing a peer to peer based > approach to finding domains that claim to be responsible for a given > phone number and validation protocols to ensure a reasonable likelihood > that a given domain actually is responsible for the phone number. In > this context, "responsible" means an administrative domain, which is at > least one of the domains, to which a PSTN call to this phone number > would be routed. Once the domain responsible for the phone number is > found, existing protocols, such as SIP, can be used for inter-domain > communications. > > Some validation protocols may be based on knowledge gathered around a > PSTN call; for example, the ability to prove a call was received over > the PSTN based on start and stop times. Other validation schemes, such > as examining fingerprints or watermarking of PSTN media to show that a > domain received a particular PSTN phone call, may also be considered by > the working group. This validation will be accomplished using publicly > available open interfaces to the PSTN, so the validation can be > performed by any domain wishing to participate. =A0The WG will select and > standardize at least one validation scheme. > > The validation mechanism requires a domain to gather and maintain > information related to PSTN calls. =A0This information is used by call > agents such as phones, SBCs and IP PBXs to route calls. =A0The WG will > define a client-server protocol between these call agents and the entity > within a domain that maintains the information. > > To help mitigate SPAM issues when using SIP between domains, the WG will > define a mechanism to enable one domain to check that incoming SIP > messages are coming from a validated phone number. =A0A phone number is > considered validated if it is coming from a domain to which the calling > domain had previously successfully placed a PSTN call. =A0The working > group will define new SIP headers and option tags, as necessary, to > enable this. > > The essential characteristic of VIPR is establishing authentication by > PSTN reachability when it is not possible to use a direct reference to > ENUM databases or other direct assertions of PSTN number > ownership. Elements such as public ENUM easily coexist with VIPR but no > direct interaction with ENUM will be required. =A0The solution set define= d > by this WG will be incrementally deployable using only existing > interfaces to the PSTN. =A0No changes will be required to existing PSTN > capabilities, no new database access is needed nor is any new support > from PSTN service providers required. > > The problem statement and some possible starting points for solutions > are further discussed in the following internet drafts which shall form > the bases of the WG documents: > > draft-rosenberg-dispatch-vipr-overview > draft-rosenberg-dispatch-vipr-reload-usage > draft-rosenberg-dispatch-vipr-pvp > draft-rosenberg-dispatch-vipr-sip-antispam > draft-rosenberg-dispatch-vipr-vap > > The working group will carefully coordinate with the security area, O&M > area, as well as the appropriate RAI WGs such as sipcore and p2psip. > _______________________________________________ > 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 Tue Jun 29 09:33:57 2010 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 6292F3A6A50 for ; Tue, 29 Jun 2010 09:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=-0.139, 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 oEuM7Wk3aCaS for ; Tue, 29 Jun 2010 09:33:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 077963A6A3C for ; Tue, 29 Jun 2010 09:33:51 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-69-4c2a20799387 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3E.09.19600.9702A2C4; Tue, 29 Jun 2010 18:34:01 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 29 Jun 2010 18:34:00 +0200 From: Christer Holmberg To: Mary Barnes Date: Tue, 29 Jun 2010 18:33:59 +0200 Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsXpdDhFF8IW5wDSUaXw6vvSDFlfQAAlIEg 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH , "DRAGE, Keith \(Keith\)" Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 29 Jun 2010 16:33:57 -0000 Hi Mary,=20 >"this problem" refers to that stated in the previous=20 >paragraph, which is stated fairly clearly. Would rewording=20 >the first sentence in the second paragraph to something like=20 >the following make it more clear to you? >=20 >" The VIPR WG will develop a peer to peer based approach to=20 >finding domains that claim to be responsible for a given=20 >phone number along with validation protocols to ensure a=20 >reasonable likelihood that a given domain actually is=20 >responsible for the phone number." The text explains what the WG will do. But, as far as I understand, the cla= imed PROBLEM is that there are existing mechanisms that for various reasons= can't be used. Also, the charter currently DOES say that the problem statement is describe= d in the drafts. So, I think it should be moved to the charter, so that we = can agree on it as part of agreeing the charter. Regards, Christer =20 >The intent is not at all that the drafts MUST be adopted in=20 >order to agree the problem statement. The charter should be=20 >standalone and as I responded to Keith, we can generalize the=20 >deliverables (to match the work items that are described in=20 >the body of the charter). Certainly, having such detailed=20 >documents at the outset can be misleading in terms of the=20 >intent of the WG, however, as with any documents that might=20 >be adopted or used as a starting point for the WG documents,=20 >change control belongs to the WG. We have lots of examples of=20 >similar situations (within RAI) that have resulted in a=20 >significantly different WG document (even as early as a -00)=20 >as compared to the individual document that was the starting=20 >point for the WG document. >=20 > Thanks, > Mary. >=20 >=20 > On Tue, Jun 29, 2010 at 8:09 AM, Christer Holmberg=20 > wrote: > > > > Hi, > > > > The second paragraph says: "The VIPR WG will address this=20 > problem..." > > > > What problem? > > > > The charter does say that the problem statement is=20 > described in the referenced drafts. But, shouldn't it be=20 > described in the charter? Now it seems that we first have to=20 > adopt the drafts in order to agree what the problem is... > > > > I also agree with Keith's comment regarding the usage of=20 > "shall be based on this and that draft" wording. > > > > Regards, > > > > Christer > > > > > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: 28. kes=E4kuuta 2010 21:00 > >> To: DRAGE, Keith (Keith) > >> Cc: DISPATCH > >> Subject: Re: [dispatch] VIPR - proposed charter version 3 > >> > >> Hi Keith, > >> > >> That's a valid concern and we can rewrite the deliverables as=20 > >> functional descriptions as we have done for other WG=20 > charters even in=20 > >> cases where documents existed (e.g., overload). =A0The=20 > current text is=20 > >> trying to say that these documents map to deliverables and can be=20 > >> used as WG documents, although as it notes these should be=20 > considered=20 > >> starting points (i.e., it's understood the proposed WG has change=20 > >> control), but certainly the current text is somewhat misleading. > >> > >> Thanks, > >> Mary. > >> > >> On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith)=20 > >> wrote: > >> > I have a major issue with including "which shall form the > >> bases of the WG documents" into the charter. To me this is=20 > confusing=20 > >> the charter discussion with the working group that might=20 > eventually=20 > >> result deciding what its deliverables, and their contents,=20 > shall be. > >> > > >> > regards > >> > > >> > Keith > >> > > >> >> -----Original Message----- > >> >> From: dispatch-bounces@ietf.org > >> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> >> Sent: Monday, June 28, 2010 6:38 PM > >> >> To: DISPATCH > >> >> Subject: [dispatch] VIPR - proposed charter version 3 > >> >> > >> >> Hi all, > >> >> > >> >> Below, please find version 3 of the VIPR proposed charter. > >> >> It's been updated to reflect ML feedback, in particular > >> VAP has been > >> >> added and clarifications have been made with regards to impacts=20 > >> >> (i.e., none) on existing PSTN interfaces. > >> >> > >> >> Regards, > >> >> Mary > >> >> (DISPATCH WG co-chair) > >> >> > >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> >> VIPR Charter Proposal (Version 3) > >> >> > >> >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) > >> >> > >> >> There are two globally deployed address spaces for=20 > communications=20 > >> >> used by more than a billion people daily - phone=20 > numbers and DNS=20 > >> >> rooted address such as web servers and email addresses. The=20 > >> >> inter-domain signaling design of SIP is primarily designed > >> for email > >> >> style addresses yet a large percentage of SIP deployments > >> mostly use > >> >> phone numbers for identifying users. The goal of this > >> working group > >> >> is to enable inter-domain communications over the the > >> Internet, using > >> >> protocols such as SIP, while still allowing people to use phone=20 > >> >> numbers to identify the person with whom they wish to=20 > communicate. > >> >> > >> >> The VIPR WG will address this problem by developing a=20 > peer to peer=20 > >> >> based approach to finding domains that claim to be > >> responsible for a > >> >> given phone number and validation protocols to ensure a=20 > reasonable=20 > >> >> likelihood that a given domain actually is responsible for > >> the phone > >> >> number. In this context, "responsible" means an administrative=20 > >> >> domain, which is at least one of the domains, to which a > >> PSTN call to > >> >> this phone number would be routed. Once the domain=20 > responsible for=20 > >> >> the phone number is found, existing protocols, such as=20 > SIP, can be=20 > >> >> used for inter-domain communications. > >> >> > >> >> Some validation protocols may be based on knowledge > >> gathered around a > >> >> PSTN call; for example, the ability to prove a call was > >> received over > >> >> the PSTN based on start and stop times. > >> >> Other validation schemes, such as examining fingerprints or=20 > >> >> watermarking of PSTN media to show that a domain received a=20 > >> >> particular PSTN phone call, may also be considered by=20 > the working=20 > >> >> group. This validation will be accomplished using publicly > >> available > >> >> open interfaces to the PSTN, so the validation can be=20 > performed by=20 > >> >> any domain wishing to participate. =A0The WG will select and=20 > >> >> standardize at least one validation scheme. > >> >> > >> >> The validation mechanism requires a domain to gather=20 > and maintain=20 > >> >> information related to PSTN calls. =A0This information is > >> used by call > >> >> agents such as phones, SBCs and IP PBXs to route calls. > > The WG will > >> >> define a client-server protocol between these call=20 > agents and the=20 > >> >> entity within a domain that maintains the information. > >> >> > >> >> To help mitigate SPAM issues when using SIP between > >> domains, the WG > >> >> will define a mechanism to enable one domain to check that > >> incoming > >> >> SIP messages are coming from a validated phone number. =A0A phone=20 > >> >> number is considered validated if it is coming from a > >> domain to which > >> >> the calling domain had previously successfully placed a > >> PSTN call. > >> >> The working group will define new SIP headers and=20 > option tags, as=20 > >> >> necessary, to enable this. > >> >> > >> >> The essential characteristic of VIPR is establishing > >> authentication > >> >> by PSTN reachability when it is not possible to use a direct=20 > >> >> reference to ENUM databases or other direct assertions of > >> PSTN number > >> >> ownership. Elements such as public ENUM easily coexist > >> with VIPR but > >> >> no direct interaction with ENUM will be required. =A0The > >> solution set > >> >> defined by this WG will be incrementally deployable using only=20 > >> >> existing interfaces to the PSTN. =A0No changes will be=20 > required to=20 > >> >> existing PSTN capabilities, no new database access is > >> needed nor is > >> >> any new support from PSTN service providers required. > >> >> > >> >> The problem statement and some possible starting points > >> for solutions > >> >> are further discussed in the following internet drafts=20 > which shall=20 > >> >> form the bases of the WG documents: > >> >> > >> >> draft-rosenberg-dispatch-vipr-overview > >> >> draft-rosenberg-dispatch-vipr-reload-usage > >> >> draft-rosenberg-dispatch-vipr-pvp > >> >> draft-rosenberg-dispatch-vipr-sip-antispam > >> >> draft-rosenberg-dispatch-vipr-vap > >> >> > >> >> The working group will carefully coordinate with the > >> security area, > >> >> O&M area, as well as the appropriate RAI WGs such as=20 > sipcore and=20 > >> >> p2psip. > >> >> _______________________________________________ > >> >> 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 pkyzivat@cisco.com Tue Jun 29 10:23:29 2010 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 623633A6817 for ; Tue, 29 Jun 2010 10:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.233 X-Spam-Level: X-Spam-Status: No, score=-10.233 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AuUPW6N-G4O for ; Tue, 29 Jun 2010 10:23:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 514DB3A6A69 for ; Tue, 29 Jun 2010 10:23:27 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAErJKUxAZnwM/2dsb2JhbACfQnGmJ5pXgnAIgiwE X-IronPort-AV: E=Sophos;i="4.53,505,1272844800"; d="scan'208";a="126854407" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2010 17:23:37 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5THNb71015515; Tue, 29 Jun 2010 17:23:37 GMT Message-ID: <4C2A2C19.1030906@cisco.com> Date: Tue, 29 Jun 2010 13:23:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 29 Jun 2010 17:23:29 -0000 DRAGE, Keith (Keith) wrote: > The UUI information is NOT ISUP. It is a transparent envelope to the entire ISDN, so it is not part of an ISDN protocol and therefore not part of an ISUP protocol. When carried by ISUP the envelope is bundled up in another envelope with other information that ISUP carries transparently. > > So I believe, and have said repeatedly in the past, that references to SIP-T are irrelevant in this case. > > The problem we do have though is that are legacy usages of this information. In particular applications in PBXs carry it between themselves in ISDN call establishment. The information itself is not standardised. If you want to migrate a PBX from DSS1 to SIP, then you have to take this information into account. The desire is not for a WG group to standardise this existing usage (which in my view would be a complete non-starter), but to allow the transfer of the existing information when migrated to a SIP environment. The information transferred does not form part of SIP, and should not be standardised as part of SIP. How many different mechanisms do we have to construct for the purpose of tunneling stuff over SIP? Its especially bad if the stuff is neither standardized nor negotiated. It then just provides more opportunity for non-interoperability. It had been my impression that this content was standardized by ITU. If nobody can bother to standardize it, then it hardly seems worth working on. Thanks, Paul > regards > > Keith > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of >> bruno.chatras@orange-ftgroup.com >> Sent: Tuesday, June 29, 2010 1:00 PM >> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >> for SIP (cuss) >> >> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >> does state that SIP-T does not come into play when there is >> no PSTN involved. >> >> At the end of clause 2 we can read the following: "4. IP >> origination - IP termination: This is a case for pure SIP. >> SIP-T (either encapsulation or translation of ISUP) does not >> come into play as there is no PSTN interworking." >> >> Besides, SIP-T would require encapsulating a full ISUP >> message (e.g. IAM) while we are interested in just one >> parameter of the message in the context of CUSS. This would I >> believe be a more severe drawback if SIP-T were used for this purpose. >> >> Bruno >> >> >>> -----Message d'origine----- >>> De : dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>> Envoyé : mardi 29 juin 2010 13:03 À : DISPATCH Objet : >> [dispatch] Fwd: >>> Re: WG Review: Call Control UUI for SIP (cuss) >>> >>> Hi, >>> >>> FYI: note the discussion below on the IETF general list. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> -------- Original Message -------- >>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>> From: Cullen Jennings >>> To: iesg@ietf.org >>> CC: IETF Discussion Mailing List >>> >>> >>> As far as I can tell, the WG says they wants to transfer some >>> information to achieve cross vendor interoperability. >>> However, what I believe the charter is actually going to do >> is exactly >>> the opposite of that. When you get your head around what >> this charter >>> is proposing, it is going to form a more or less opaque >> container for >>> transporting proprietary information in a SIP header. It's hard to >>> imagine how this will help interoperability. >>> >>> If we wanted to have interoperability, the charter would say what >>> information needs to be transferred and have the WG define a way to >>> get it between systems in an operable way. >>> What the charter for this WG actually says they are going to do is >>> make a special container for transfer proprietary information. >>> There's not even willing to say what that proprietary >> information is >>> used for other than things ISDN UUI which is a non >> interoperable and >>> fairly proprietary field in ISDN. >>> Furthermore they have asserted that existing containers >> such as SIP-T >>> or SIP bodies can't be used for reasons that are hard to >> describe. (I >>> reject the idea that because the call might not involved >> the PSTN, it >>> can't use SIP-T). >>> >>> I think the folks that want to do this should get a much clear >>> explanation of how this results in interoperability and why exist >>> approach such as SIP-T will not work before this is chartered. >>> >>> I do think there is a need to standardize some important >> call control >>> information used in call centers and related places. >>> However, the "we need a standard container to exchange secret >>> information WG" is a bad idea and violates the sprit of the >> SIP change >>> process not to mention the mission of the IETF. >>> >>> In summary, I'm in favor of figuring out what the problems >> are people >>> hope to solve with this WG and figuring out a way to write >>> interoperable standards to achieve that. However, I think >> this charter >>> should be rejected by the IESG and sent back to the drawing >> board. The >>> RAI area has things of higher priority items to work on than a SIP >>> header for transfer proprietary data. >>> >>> >>> >>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>> >>>> A new IETF working group has been proposed in the Real-time >>>> Applications and Infrastructure Area. The IESG has not >>> made any determination as yet. >>>> The following draft charter was submitted, and is provided for >>>> informational purposes only. Please send your comments to >> the IESG >>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>> >>>> Call Control UUI for SIP (cuss) >>>> -------------------------------------------------- >>>> Current Status: Proposed Working Group >>>> >>>> Last modified: 2010-06-21 >>>> >>>> Chair(s): >>>> TBD >>>> >>>> Real-time Applications and Infrastructure Area Director(s): >>>> Gonzalo Camarillo >> Robert Sparks >>>> >>>> >>>> Real-time Applications and Infrastructure Area Advisor: >>>> Gonzalo Camarillo >>>> >>>> Mailing Lists: TBD >>>> >>>> Description of Working Group: >>>> >>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>> define a Session Initiation Protocol (SIP) mechanism for >>> transporting >>>> call-control related user-to-user information (UUI) between User >>>> Agents. >>>> >>>> The mechanism developed in this working group is >> applicable in the >>>> following situations: >>>> >>>> 1. The information is generated and consumed by an >> application using >>>> SIP during session setup but the application is not necessarily >>>> even SIP aware. >>>> 2. The behavior of SIP entities that support it is not >> significantly >>>> changed (as discussed in Section 4 of RFC 5727). >>>> 3. Generally only the User Agent Client (UAC) and User >> Agent Server >>>> (UAS) are interested in the information. >>>> 4. The information is expected to survive retargeting, >> redirection, >>>> and transfers. >>>> 5. SIP elements may need to apply policy about passing >> and screening >>>> the information. >>>> 6. Multi-vendor interoperability is important. >>>> >>>> This mechanism is not applicable in the following situations: >>>> >>>> 1. The behavior of SIP entities that support it is significantly >>>> changed (as discussed in Section 4 of RFC 5727). >>>> 2. The information is generated and consumed at the SIP >> layer by SIP >>>> elements. >>>> 3. SIP elements besides the UAC and UAS might be interested in >>>> consuming (beyond applying policy) the information. >>>> 4. There are specific privacy issues involved with the information >>>> being transported (e.g., geolocation or emergency-related >>>> information). >>>> >>>> User data of the mechanism will be clearly marked with the >>>> application, encoding, semantics, and content type, >>> allowing policy to >>>> be applied by UAs. The working group will define the >>> information that >>>> each application must specify to utilize the mechanism. >>> This type of >>>> application-specific information will be specified in >>> standards-track >>>> documents. >>>> >>>> One important application of this mechanism is interworking >>> with the >>>> ISDN User to User Information Service. This application >> defined by >>>> ITU-T Q.931 is extensively deployed in the PSTN today >>> supporting such >>>> applications as contact centers, call centers, and automatic call >>>> distributors (ACDs). A major barrier to the movement of these >>>> applications to SIP is the lack of a standard mechanism to >>> transport >>>> this information in SIP. For interworking with ISDN, minimal >>>> information about the content of the UUI is available to >>> the PSTN-SIP >>>> gateways. In this case only, the content will just >>> indicate ISDN UUI >>>> Service 1 interworking rather than the actual content. >>>> >>>> Call control UUI is user information conveyed between user agents >>>> during call control operations. As a result, the >>> information must be >>>> conveyed with the INVITE transaction, and must survive proxy >>>> retargeting, redirection, and transfers. The mechanism >>> must utilize a >>>> minimum of SIP extensions since it will need to be >>> supported by many >>>> simple SIP user agents such as PSTN gateways. The mechanism must >>>> interwork with the existing ISDN service but should also be >>> extensible >>>> for use by other applications and non-ISDN protocols. >>>> >>>> Even though interworking with the PSTN is an important >> requirement, >>>> call control UUI can be exchanged between native SIP >>> clients that do >>>> not have any ISUP support. Therefore, existing SIP-T >>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>> requirements to transport this type of information. >>>> >>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>> considered by the working group since the UUI contents carry >>>> information that must be conveyed during session setup at >> the user >>>> agent - the information must be conveyed with the INVITE >>> transaction. >>>> The information 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. >>>> >>>> The group will produce: >>>> >>>> - A problem statement and requirements document for >>> implementing a SIP >>>> call control UUI mechanism >>>> >>>> - A specification of the SIP extension to best meet those >>> requirements. >>>> Goals and Milestones >>>> ==================== >>>> >>>> Sep 10 - Problem statement and requirements document to IESG >>>> (Informational) >>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >>> Cullen Jennings >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> >>> >>> _______________________________________________ >>> 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 gao.yang2@zte.com.cn Tue Jun 29 18:11:43 2010 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 77E743A69E3 for ; Tue, 29 Jun 2010 18:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.512 X-Spam-Level: X-Spam-Status: No, score=-99.512 tagged_above=-999 required=5 tests=[AWL=2.326, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 SkOt2asZ5EdD for ; Tue, 29 Jun 2010 18:11:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id ACD223A69FE for ; Tue, 29 Jun 2010 18:11:41 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 55234992332426; Wed, 30 Jun 2010 09:11:14 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 62981.2776214488; Wed, 30 Jun 2010 09:04:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5U1BXGn069267; Wed, 30 Jun 2010 09:11:33 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: dispatch@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 30 Jun 2010 09:08:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-30 09:11:31, Serialize complete at 2010-06-30 09:11:31 Content-Type: multipart/alternative; boundary="=_alternative 00067C1148257752_=" X-MAIL: mse2.zte.com.cn o5U1BXGn069267 Subject: [dispatch] About Final Charter for Session-ID: 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, 30 Jun 2010 01:11:43 -0000 This is a multipart message in MIME format. --=_alternative 00067C1148257752_= Content-Type: text/plain; charset="US-ASCII" Hi, By the charter and the original text named draft-kaplan-sip-session-id-02, this work is just focused on troubleshooting usage. But I was told that *someone* want to use this session-id in Replace header usage, to do dialog-matching. I think this would be UPDATE of RFC3891. So, I'd like to confirm that this charter and coming draft would not do such thing normatively. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00067C1148257752_= Content-Type: text/html; charset="US-ASCII"
Hi,

By the charter and the original text named draft-kaplan-sip-session-id-02, this work is just focused on troubleshooting usage.

But I was told that *someone* want to use this session-id in Replace header usage, to do dialog-matching. I think this would be UPDATE of RFC3891.

So, I'd like to confirm that this charter and coming draft would not do such thing normatively.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00067C1148257752_=-- From gonzalo.camarillo@ericsson.com Tue Jun 29 23:49:22 2010 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 B51333A6C34; Tue, 29 Jun 2010 23:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4uWJ0dzrM9K; Tue, 29 Jun 2010 23:49:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3CB8D3A6A7F; Tue, 29 Jun 2010 23:49:20 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-21-4c2ae8faa647 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 27.54.19600.AF8EA2C4; Wed, 30 Jun 2010 08:49:30 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 08:48:52 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 08:48:51 +0200 Message-ID: <4C2AE8D3.5080801@ericsson.com> Date: Wed, 30 Jun 2010 09:48:51 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "ietf@ietf.org" References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Jun 2010 06:48:51.0532 (UTC) FILETIME=[4CB7B8C0:01CB1820] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH , Roland Jesske Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) 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, 30 Jun 2010 06:49:22 -0000 Hi, please, keep the DISPATCH list in the cc: of this thread so that all interested parties can participate in this discussion. Thanks, Gonzalo On 29/06/2010 6:08 PM, Laura Liess wrote: > Cullen, > > Bruno is right. > > SIP-T is used today for tunneling ISUP in SIP. In many cases people > don't implement SIP-T at all, because they intend to migrate the > network to full SIP, but still need to interwork with PSTN for a > while. Should we require ISUP-capabilities for SIP application > servers? We just need a way to transport a piece of data between SIP > application servers, SIP end devices and PSTN. The solution can not be > ISUP. > >>> However, I >>> think this charter should be rejected by the IESG and sent >>> back to the drawing board. > > The need for UUI was recognized back in 2006, when we had the first > draft with this proposal see > http://tools.ietf.org/id/draft-johnston-sipping-cc-uui-00.txt . We > discussed the issue a number of times and people stated their need for > this. We have now 2010. > > Laura > > > 2010/6/29 : >> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 does state that SIP-T does not come into play when there is no PSTN involved. >> >> At the end of clause 2 we can read the following: "4. IP origination - IP termination: This is a case for pure SIP. SIP-T (either encapsulation or translation of ISUP) does not come into play as there is no PSTN interworking." >> >> Besides, SIP-T would require encapsulating a full ISUP message (e.g. IAM) while we are interested in just one parameter of the message in the context of CUSS. This would I believe be a more severe drawback if SIP-T were used for this purpose. >> >> Bruno >> >> >>> -----Message d'origine----- >>> De : dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>> Envoyé : mardi 29 juin 2010 13:03 >>> À : DISPATCH >>> Objet : [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) >>> >>> Hi, >>> >>> FYI: note the discussion below on the IETF general list. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> -------- Original Message -------- >>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>> From: Cullen Jennings >>> To: iesg@ietf.org >>> CC: IETF Discussion Mailing List >>> >>> >>> As far as I can tell, the WG says they wants to transfer some >>> information to achieve cross vendor interoperability. >>> However, what I believe the charter is actually going to do >>> is exactly the opposite of that. When you get your head >>> around what this charter is proposing, it is going to form a >>> more or less opaque container for transporting proprietary >>> information in a SIP header. It's hard to imagine how this >>> will help interoperability. >>> >>> If we wanted to have interoperability, the charter would say >>> what information needs to be transferred and have the WG >>> define a way to get it between systems in an operable way. >>> What the charter for this WG actually says they are going to >>> do is make a special container for transfer proprietary >>> information. There's not even willing to say what that >>> proprietary information is used for other than things ISDN >>> UUI which is a non interoperable and fairly proprietary >>> field in ISDN. >>> Furthermore they have asserted that existing containers such >>> as SIP-T or SIP bodies can't be used for reasons that are >>> hard to describe. (I reject the idea that because the call >>> might not involved the PSTN, it can't use SIP-T). >>> >>> I think the folks that want to do this should get a much >>> clear explanation of how this results in interoperability and >>> why exist approach such as SIP-T will not work before this is >>> chartered. >>> >>> I do think there is a need to standardize some important call >>> control information used in call centers and related places. >>> However, the "we need a standard container to exchange secret >>> information WG" is a bad idea and violates the sprit of the >>> SIP change process not to mention the mission of the IETF. >>> >>> In summary, I'm in favor of figuring out what the problems >>> are people hope to solve with this WG and figuring out a way >>> to write interoperable standards to achieve that. However, I >>> think this charter should be rejected by the IESG and sent >>> back to the drawing board. The RAI area has things of higher >>> priority items to work on than a SIP header for transfer >>> proprietary data. >>> >>> >>> >>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>> >>>> A new IETF working group has been proposed in the Real-time >>>> Applications and Infrastructure Area. The IESG has not >>> made any determination as yet. >>>> The following draft charter was submitted, and is provided for >>>> informational purposes only. Please send your comments to the IESG >>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>> >>>> Call Control UUI for SIP (cuss) >>>> -------------------------------------------------- >>>> Current Status: Proposed Working Group >>>> >>>> Last modified: 2010-06-21 >>>> >>>> Chair(s): >>>> TBD >>>> >>>> Real-time Applications and Infrastructure Area Director(s): >>>> Gonzalo Camarillo Robert Sparks >>>> >>>> >>>> Real-time Applications and Infrastructure Area Advisor: >>>> Gonzalo Camarillo >>>> >>>> Mailing Lists: TBD >>>> >>>> Description of Working Group: >>>> >>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>> define a Session Initiation Protocol (SIP) mechanism for >>> transporting >>>> call-control related user-to-user information (UUI) between User >>>> Agents. >>>> >>>> The mechanism developed in this working group is applicable in the >>>> following situations: >>>> >>>> 1. The information is generated and consumed by an application using >>>> SIP during session setup but the application is not necessarily >>>> even SIP aware. >>>> 2. The behavior of SIP entities that support it is not significantly >>>> changed (as discussed in Section 4 of RFC 5727). >>>> 3. Generally only the User Agent Client (UAC) and User Agent Server >>>> (UAS) are interested in the information. >>>> 4. The information is expected to survive retargeting, redirection, >>>> and transfers. >>>> 5. SIP elements may need to apply policy about passing and screening >>>> the information. >>>> 6. Multi-vendor interoperability is important. >>>> >>>> This mechanism is not applicable in the following situations: >>>> >>>> 1. The behavior of SIP entities that support it is significantly >>>> changed (as discussed in Section 4 of RFC 5727). >>>> 2. The information is generated and consumed at the SIP layer by SIP >>>> elements. >>>> 3. SIP elements besides the UAC and UAS might be interested in >>>> consuming (beyond applying policy) the information. >>>> 4. There are specific privacy issues involved with the information >>>> being transported (e.g., geolocation or emergency-related >>>> information). >>>> >>>> User data of the mechanism will be clearly marked with the >>>> application, encoding, semantics, and content type, >>> allowing policy to >>>> be applied by UAs. The working group will define the >>> information that >>>> each application must specify to utilize the mechanism. >>> This type of >>>> application-specific information will be specified in >>> standards-track >>>> documents. >>>> >>>> One important application of this mechanism is interworking >>> with the >>>> ISDN User to User Information Service. This application defined by >>>> ITU-T Q.931 is extensively deployed in the PSTN today >>> supporting such >>>> applications as contact centers, call centers, and automatic call >>>> distributors (ACDs). A major barrier to the movement of these >>>> applications to SIP is the lack of a standard mechanism to >>> transport >>>> this information in SIP. For interworking with ISDN, minimal >>>> information about the content of the UUI is available to >>> the PSTN-SIP >>>> gateways. In this case only, the content will just >>> indicate ISDN UUI >>>> Service 1 interworking rather than the actual content. >>>> >>>> Call control UUI is user information conveyed between user agents >>>> during call control operations. As a result, the >>> information must be >>>> conveyed with the INVITE transaction, and must survive proxy >>>> retargeting, redirection, and transfers. The mechanism >>> must utilize a >>>> minimum of SIP extensions since it will need to be >>> supported by many >>>> simple SIP user agents such as PSTN gateways. The mechanism must >>>> interwork with the existing ISDN service but should also be >>> extensible >>>> for use by other applications and non-ISDN protocols. >>>> >>>> Even though interworking with the PSTN is an important requirement, >>>> call control UUI can be exchanged between native SIP >>> clients that do >>>> not have any ISUP support. Therefore, existing SIP-T >>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>> requirements to transport this type of information. >>>> >>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>> considered by the working group since the UUI contents carry >>>> information that must be conveyed during session setup at the user >>>> agent - the information must be conveyed with the INVITE >>> transaction. >>>> The information 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. >>>> >>>> The group will produce: >>>> >>>> - A problem statement and requirements document for >>> implementing a SIP >>>> call control UUI mechanism >>>> >>>> - A specification of the SIP extension to best meet those >>> requirements. >>>> >>>> Goals and Milestones >>>> ==================== >>>> >>>> Sep 10 - Problem statement and requirements document to IESG >>>> (Informational) >>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >>> >>> Cullen Jennings >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From gonzalo.camarillo@ericsson.com Tue Jun 29 23:50:49 2010 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 62D623A6A8B; Tue, 29 Jun 2010 23:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.177 X-Spam-Level: X-Spam-Status: No, score=-105.177 tagged_above=-999 required=5 tests=[AWL=1.422, 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 KEMdHYIffG+k; Tue, 29 Jun 2010 23:50:44 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 547A23A6A11; Tue, 29 Jun 2010 23:50:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-5e-4c2ae94de781 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.B0.10125.D49EA2C4; Wed, 30 Jun 2010 08:50:53 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 08:50:53 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 08:50:52 +0200 Message-ID: <4C2AE94C.4020707@ericsson.com> Date: Wed, 30 Jun 2010 09:50:52 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> In-Reply-To: <4C2A2C19.1030906@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 30 Jun 2010 06:50:52.0811 (UTC) FILETIME=[95016DB0:01CB1820] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" , "DRAGE, Keith \(Keith\)" , ietf@ietf.org Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 30 Jun 2010 06:50:49 -0000 Hi, please keep both the IETF and the DISPATCH mailing lists in the recipients list in this discussion. Cheers, Gonzalo On 29/06/2010 8:23 PM, Paul Kyzivat wrote: > > > DRAGE, Keith (Keith) wrote: >> The UUI information is NOT ISUP. It is a transparent envelope to the entire ISDN, so it is not part of an ISDN protocol and therefore not part of an ISUP protocol. When carried by ISUP the envelope is bundled up in another envelope with other information that ISUP carries transparently. >> >> So I believe, and have said repeatedly in the past, that references to SIP-T are irrelevant in this case. >> >> The problem we do have though is that are legacy usages of this information. In particular applications in PBXs carry it between themselves in ISDN call establishment. The information itself is not standardised. If you want to migrate a PBX from DSS1 to SIP, then you have to take this information into account. The desire is not for a WG group to standardise this existing usage (which in my view would be a complete non-starter), but to allow the transfer of the existing information when migrated to a SIP environment. The information transferred does not form part of SIP, and should not be standardised as part of SIP. > > How many different mechanisms do we have to construct for the purpose of > tunneling stuff over SIP? > > Its especially bad if the stuff is neither standardized nor negotiated. > It then just provides more opportunity for non-interoperability. > > It had been my impression that this content was standardized by ITU. > If nobody can bother to standardize it, then it hardly seems worth > working on. > > Thanks, > Paul > >> regards >> >> Keith >> >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>> bruno.chatras@orange-ftgroup.com >>> Sent: Tuesday, June 29, 2010 1:00 PM >>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>> for SIP (cuss) >>> >>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>> does state that SIP-T does not come into play when there is >>> no PSTN involved. >>> >>> At the end of clause 2 we can read the following: "4. IP >>> origination - IP termination: This is a case for pure SIP. >>> SIP-T (either encapsulation or translation of ISUP) does not >>> come into play as there is no PSTN interworking." >>> >>> Besides, SIP-T would require encapsulating a full ISUP >>> message (e.g. IAM) while we are interested in just one >>> parameter of the message in the context of CUSS. This would I >>> believe be a more severe drawback if SIP-T were used for this purpose. >>> >>> Bruno >>> >>> >>>> -----Message d'origine----- >>>> De : dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>> Envoyé : mardi 29 juin 2010 13:03 À : DISPATCH Objet : >>> [dispatch] Fwd: >>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>> >>>> Hi, >>>> >>>> FYI: note the discussion below on the IETF general list. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> -------- Original Message -------- >>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>> From: Cullen Jennings >>>> To: iesg@ietf.org >>>> CC: IETF Discussion Mailing List >>>> >>>> >>>> As far as I can tell, the WG says they wants to transfer some >>>> information to achieve cross vendor interoperability. >>>> However, what I believe the charter is actually going to do >>> is exactly >>>> the opposite of that. When you get your head around what >>> this charter >>>> is proposing, it is going to form a more or less opaque >>> container for >>>> transporting proprietary information in a SIP header. It's hard to >>>> imagine how this will help interoperability. >>>> >>>> If we wanted to have interoperability, the charter would say what >>>> information needs to be transferred and have the WG define a way to >>>> get it between systems in an operable way. >>>> What the charter for this WG actually says they are going to do is >>>> make a special container for transfer proprietary information. >>>> There's not even willing to say what that proprietary >>> information is >>>> used for other than things ISDN UUI which is a non >>> interoperable and >>>> fairly proprietary field in ISDN. >>>> Furthermore they have asserted that existing containers >>> such as SIP-T >>>> or SIP bodies can't be used for reasons that are hard to >>> describe. (I >>>> reject the idea that because the call might not involved >>> the PSTN, it >>>> can't use SIP-T). >>>> >>>> I think the folks that want to do this should get a much clear >>>> explanation of how this results in interoperability and why exist >>>> approach such as SIP-T will not work before this is chartered. >>>> >>>> I do think there is a need to standardize some important >>> call control >>>> information used in call centers and related places. >>>> However, the "we need a standard container to exchange secret >>>> information WG" is a bad idea and violates the sprit of the >>> SIP change >>>> process not to mention the mission of the IETF. >>>> >>>> In summary, I'm in favor of figuring out what the problems >>> are people >>>> hope to solve with this WG and figuring out a way to write >>>> interoperable standards to achieve that. However, I think >>> this charter >>>> should be rejected by the IESG and sent back to the drawing >>> board. The >>>> RAI area has things of higher priority items to work on than a SIP >>>> header for transfer proprietary data. >>>> >>>> >>>> >>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>> >>>>> A new IETF working group has been proposed in the Real-time >>>>> Applications and Infrastructure Area. The IESG has not >>>> made any determination as yet. >>>>> The following draft charter was submitted, and is provided for >>>>> informational purposes only. Please send your comments to >>> the IESG >>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>> >>>>> Call Control UUI for SIP (cuss) >>>>> -------------------------------------------------- >>>>> Current Status: Proposed Working Group >>>>> >>>>> Last modified: 2010-06-21 >>>>> >>>>> Chair(s): >>>>> TBD >>>>> >>>>> Real-time Applications and Infrastructure Area Director(s): >>>>> Gonzalo Camarillo >>> Robert Sparks >>>>> >>>>> >>>>> Real-time Applications and Infrastructure Area Advisor: >>>>> Gonzalo Camarillo >>>>> >>>>> Mailing Lists: TBD >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>> define a Session Initiation Protocol (SIP) mechanism for >>>> transporting >>>>> call-control related user-to-user information (UUI) between User >>>>> Agents. >>>>> >>>>> The mechanism developed in this working group is >>> applicable in the >>>>> following situations: >>>>> >>>>> 1. The information is generated and consumed by an >>> application using >>>>> SIP during session setup but the application is not necessarily >>>>> even SIP aware. >>>>> 2. The behavior of SIP entities that support it is not >>> significantly >>>>> changed (as discussed in Section 4 of RFC 5727). >>>>> 3. Generally only the User Agent Client (UAC) and User >>> Agent Server >>>>> (UAS) are interested in the information. >>>>> 4. The information is expected to survive retargeting, >>> redirection, >>>>> and transfers. >>>>> 5. SIP elements may need to apply policy about passing >>> and screening >>>>> the information. >>>>> 6. Multi-vendor interoperability is important. >>>>> >>>>> This mechanism is not applicable in the following situations: >>>>> >>>>> 1. The behavior of SIP entities that support it is significantly >>>>> changed (as discussed in Section 4 of RFC 5727). >>>>> 2. The information is generated and consumed at the SIP >>> layer by SIP >>>>> elements. >>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>> consuming (beyond applying policy) the information. >>>>> 4. There are specific privacy issues involved with the information >>>>> being transported (e.g., geolocation or emergency-related >>>>> information). >>>>> >>>>> User data of the mechanism will be clearly marked with the >>>>> application, encoding, semantics, and content type, >>>> allowing policy to >>>>> be applied by UAs. The working group will define the >>>> information that >>>>> each application must specify to utilize the mechanism. >>>> This type of >>>>> application-specific information will be specified in >>>> standards-track >>>>> documents. >>>>> >>>>> One important application of this mechanism is interworking >>>> with the >>>>> ISDN User to User Information Service. This application >>> defined by >>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>> supporting such >>>>> applications as contact centers, call centers, and automatic call >>>>> distributors (ACDs). A major barrier to the movement of these >>>>> applications to SIP is the lack of a standard mechanism to >>>> transport >>>>> this information in SIP. For interworking with ISDN, minimal >>>>> information about the content of the UUI is available to >>>> the PSTN-SIP >>>>> gateways. In this case only, the content will just >>>> indicate ISDN UUI >>>>> Service 1 interworking rather than the actual content. >>>>> >>>>> Call control UUI is user information conveyed between user agents >>>>> during call control operations. As a result, the >>>> information must be >>>>> conveyed with the INVITE transaction, and must survive proxy >>>>> retargeting, redirection, and transfers. The mechanism >>>> must utilize a >>>>> minimum of SIP extensions since it will need to be >>>> supported by many >>>>> simple SIP user agents such as PSTN gateways. The mechanism must >>>>> interwork with the existing ISDN service but should also be >>>> extensible >>>>> for use by other applications and non-ISDN protocols. >>>>> >>>>> Even though interworking with the PSTN is an important >>> requirement, >>>>> call control UUI can be exchanged between native SIP >>>> clients that do >>>>> not have any ISUP support. Therefore, existing SIP-T >>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>> requirements to transport this type of information. >>>>> >>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>> considered by the working group since the UUI contents carry >>>>> information that must be conveyed during session setup at >>> the user >>>>> agent - the information must be conveyed with the INVITE >>>> transaction. >>>>> The information 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. >>>>> >>>>> The group will produce: >>>>> >>>>> - A problem statement and requirements document for >>>> implementing a SIP >>>>> call control UUI mechanism >>>>> >>>>> - A specification of the SIP extension to best meet those >>>> requirements. >>>>> Goals and Milestones >>>>> ==================== >>>>> >>>>> Sep 10 - Problem statement and requirements document to IESG >>>>> (Informational) >>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>> >>>> Cullen Jennings >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 keith.drage@alcatel-lucent.com Wed Jun 30 03:33:07 2010 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 A9C7B3A69AA for ; Wed, 30 Jun 2010 03:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.935 X-Spam-Level: X-Spam-Status: No, score=-4.935 tagged_above=-999 required=5 tests=[AWL=1.314, 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 dgdcAMdDBK-R for ; Wed, 30 Jun 2010 03:33:01 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 1714F3A698E for ; Wed, 30 Jun 2010 03:32:53 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5UAUBah028547 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jun 2010 12:32:33 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 30 Jun 2010 12:32:00 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Wed, 30 Jun 2010 12:31:49 +0200 Thread-Topic: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcsXr9P2thPWa19CT6uV1rHNYZ4BmAAj0Qaw Message-ID: References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> In-Reply-To: <4C2A2C19.1030906@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 30 Jun 2010 10:33:08 -0000 > It had been my impression that this content was standardized by ITU. > If nobody can bother to standardize it, then it hardly seems=20 > worth working on. >=20 So you believe that removing all the headers from SIP where nobody has both= ered to standardise the contents is also valid? ITU-T did not standardise the contents, only the protocol discriminator. It= was recognised at the time this was decided (somewhere before 1984) that s= uch applications could not be standardised. Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, June 29, 2010 6:24 PM > To: DRAGE, Keith (Keith) > Cc: bruno.chatras@orange-ftgroup.com;=20 > Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org > Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI=20 > for SIP (cuss) >=20 >=20 >=20 > DRAGE, Keith (Keith) wrote: > > The UUI information is NOT ISUP. It is a transparent=20 > envelope to the entire ISDN, so it is not part of an ISDN=20 > protocol and therefore not part of an ISUP protocol. When=20 > carried by ISUP the envelope is bundled up in another=20 > envelope with other information that ISUP carries transparently. > >=20 > > So I believe, and have said repeatedly in the past, that=20 > references to SIP-T are irrelevant in this case. > >=20 > > The problem we do have though is that are legacy usages of=20 > this information. In particular applications in PBXs carry it=20 > between themselves in ISDN call establishment. The=20 > information itself is not standardised. If you want to=20 > migrate a PBX from DSS1 to SIP, then you have to take this=20 > information into account. The desire is not for a WG group to=20 > standardise this existing usage (which in my view would be a=20 > complete non-starter), but to allow the transfer of the=20 > existing information when migrated to a SIP environment. The=20 > information transferred does not form part of SIP, and should=20 > not be standardised as part of SIP. >=20 > How many different mechanisms do we have to construct for the=20 > purpose of tunneling stuff over SIP? >=20 > Its especially bad if the stuff is neither standardized nor=20 > negotiated. > It then just provides more opportunity for non-interoperability. >=20 > It had been my impression that this content was standardized by ITU. > If nobody can bother to standardize it, then it hardly seems=20 > worth working on. >=20 > Thanks, > Paul >=20 > > regards > >=20 > > Keith > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of=20 > >> bruno.chatras@orange-ftgroup.com > >> Sent: Tuesday, June 29, 2010 1:00 PM > >> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org > >> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control=20 > UUI for SIP=20 > >> (cuss) > >> > >> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 does=20 > >> state that SIP-T does not come into play when there is no PSTN=20 > >> involved. > >> > >> At the end of clause 2 we can read the following: "4. IP=20 > origination=20 > >> - IP termination: This is a case for pure SIP. > >> SIP-T (either encapsulation or translation of ISUP) does not come=20 > >> into play as there is no PSTN interworking." > >> > >> Besides, SIP-T would require encapsulating a full ISUP=20 > message (e.g.=20 > >> IAM) while we are interested in just one parameter of the=20 > message in=20 > >> the context of CUSS. This would I believe be a more severe=20 > drawback=20 > >> if SIP-T were used for this purpose. > >> > >> Bruno > >> > >> > >>> -----Message d'origine----- > >>> De : dispatch-bounces@ietf.org > >>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo=20 > Camarillo=20 > >>> Envoy=E9 : mardi 29 juin 2010 13:03 =C0 : DISPATCH Objet : > >> [dispatch] Fwd:=20 > >>> Re: WG Review: Call Control UUI for SIP (cuss) > >>> > >>> Hi, > >>> > >>> FYI: note the discussion below on the IETF general list. > >>> > >>> Cheers, > >>> > >>> Gonzalo > >>> > >>> -------- Original Message -------- > >>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) > >>> Date: Mon, 28 Jun 2010 20:24:23 +0200 > >>> From: Cullen Jennings > >>> To: iesg@ietf.org > >>> CC: IETF Discussion Mailing List > >>> > >>> > >>> As far as I can tell, the WG says they wants to transfer some=20 > >>> information to achieve cross vendor interoperability. > >>> However, what I believe the charter is actually going to do > >> is exactly > >>> the opposite of that. When you get your head around what > >> this charter > >>> is proposing, it is going to form a more or less opaque > >> container for > >>> transporting proprietary information in a SIP header.=20 > It's hard to=20 > >>> imagine how this will help interoperability. > >>> > >>> If we wanted to have interoperability, the charter would say what=20 > >>> information needs to be transferred and have the WG=20 > define a way to=20 > >>> get it between systems in an operable way. > >>> What the charter for this WG actually says they are going=20 > to do is=20 > >>> make a special container for transfer proprietary information. > >>> There's not even willing to say what that proprietary > >> information is > >>> used for other than things ISDN UUI which is a non > >> interoperable and > >>> fairly proprietary field in ISDN. > >>> Furthermore they have asserted that existing containers > >> such as SIP-T > >>> or SIP bodies can't be used for reasons that are hard to > >> describe. (I > >>> reject the idea that because the call might not involved > >> the PSTN, it > >>> can't use SIP-T). > >>> > >>> I think the folks that want to do this should get a much clear=20 > >>> explanation of how this results in interoperability and why exist=20 > >>> approach such as SIP-T will not work before this is chartered. > >>> > >>> I do think there is a need to standardize some important > >> call control > >>> information used in call centers and related places. > >>> However, the "we need a standard container to exchange secret=20 > >>> information WG" is a bad idea and violates the sprit of the > >> SIP change > >>> process not to mention the mission of the IETF. > >>> > >>> In summary, I'm in favor of figuring out what the problems > >> are people > >>> hope to solve with this WG and figuring out a way to write=20 > >>> interoperable standards to achieve that. However, I think > >> this charter > >>> should be rejected by the IESG and sent back to the drawing > >> board. The > >>> RAI area has things of higher priority items to work on=20 > than a SIP=20 > >>> header for transfer proprietary data. > >>> > >>> > >>> > >>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: > >>> > >>>> A new IETF working group has been proposed in the Real-time=20 > >>>> Applications and Infrastructure Area. The IESG has not > >>> made any determination as yet. > >>>> The following draft charter was submitted, and is provided for=20 > >>>> informational purposes only. Please send your comments to > >> the IESG > >>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. > >>>> > >>>> Call Control UUI for SIP (cuss) > >>>> -------------------------------------------------- > >>>> Current Status: Proposed Working Group > >>>> > >>>> Last modified: 2010-06-21 > >>>> > >>>> Chair(s): > >>>> TBD > >>>> > >>>> Real-time Applications and Infrastructure Area Director(s): > >>>> Gonzalo Camarillo > >> Robert Sparks > >>>> > >>>> > >>>> Real-time Applications and Infrastructure Area Advisor: > >>>> Gonzalo Camarillo > >>>> > >>>> Mailing Lists: TBD > >>>> > >>>> Description of Working Group: > >>>> > >>>> The Call Control UUI for SIP (CUSS) working group is=20 > chartered to=20 > >>>> define a Session Initiation Protocol (SIP) mechanism for > >>> transporting > >>>> call-control related user-to-user information (UUI) between User=20 > >>>> Agents. > >>>> > >>>> The mechanism developed in this working group is > >> applicable in the > >>>> following situations: > >>>> > >>>> 1. The information is generated and consumed by an > >> application using > >>>> SIP during session setup but the application is not necessarily > >>>> even SIP aware. > >>>> 2. The behavior of SIP entities that support it is not > >> significantly > >>>> changed (as discussed in Section 4 of RFC 5727). > >>>> 3. Generally only the User Agent Client (UAC) and User > >> Agent Server > >>>> (UAS) are interested in the information. > >>>> 4. The information is expected to survive retargeting, > >> redirection, > >>>> and transfers. > >>>> 5. SIP elements may need to apply policy about passing > >> and screening > >>>> the information. > >>>> 6. Multi-vendor interoperability is important. > >>>> > >>>> This mechanism is not applicable in the following situations: > >>>> > >>>> 1. The behavior of SIP entities that support it is significantly > >>>> changed (as discussed in Section 4 of RFC 5727). > >>>> 2. The information is generated and consumed at the SIP > >> layer by SIP > >>>> elements. > >>>> 3. SIP elements besides the UAC and UAS might be interested in > >>>> consuming (beyond applying policy) the information. > >>>> 4. There are specific privacy issues involved with the=20 > information > >>>> being transported (e.g., geolocation or emergency-related > >>>> information). > >>>> > >>>> User data of the mechanism will be clearly marked with the=20 > >>>> application, encoding, semantics, and content type, > >>> allowing policy to > >>>> be applied by UAs. The working group will define the > >>> information that > >>>> each application must specify to utilize the mechanism.=20 > >>> This type of > >>>> application-specific information will be specified in > >>> standards-track > >>>> documents. > >>>> > >>>> One important application of this mechanism is interworking > >>> with the > >>>> ISDN User to User Information Service. This application > >> defined by > >>>> ITU-T Q.931 is extensively deployed in the PSTN today > >>> supporting such > >>>> applications as contact centers, call centers, and=20 > automatic call=20 > >>>> distributors (ACDs). A major barrier to the movement of these=20 > >>>> applications to SIP is the lack of a standard mechanism to > >>> transport > >>>> this information in SIP. For interworking with ISDN, minimal=20 > >>>> information about the content of the UUI is available to > >>> the PSTN-SIP > >>>> gateways. In this case only, the content will just > >>> indicate ISDN UUI > >>>> Service 1 interworking rather than the actual content. > >>>> > >>>> Call control UUI is user information conveyed between=20 > user agents=20 > >>>> during call control operations. As a result, the > >>> information must be > >>>> conveyed with the INVITE transaction, and must survive proxy=20 > >>>> retargeting, redirection, and transfers. The mechanism > >>> must utilize a > >>>> minimum of SIP extensions since it will need to be > >>> supported by many > >>>> simple SIP user agents such as PSTN gateways. The=20 > mechanism must=20 > >>>> interwork with the existing ISDN service but should also be > >>> extensible > >>>> for use by other applications and non-ISDN protocols. > >>>> > >>>> Even though interworking with the PSTN is an important > >> requirement, > >>>> call control UUI can be exchanged between native SIP > >>> clients that do > >>>> not have any ISUP support. Therefore, existing SIP-T=20 > >>>> encapsulation-based approaches defined in RFC3372 do not=20 > meet the=20 > >>>> requirements to transport this type of information. > >>>> > >>>> Mechanisms based on the SIP INFO method, RFC2976, will not be=20 > >>>> considered by the working group since the UUI contents carry=20 > >>>> information that must be conveyed during session setup at > >> the user > >>>> agent - the information must be conveyed with the INVITE > >>> transaction. > >>>> The information must be passed with the session setup request=20 > >>>> (INVITE), responses to that INVITE, or session > >> termination requests. > >>>> As a result, it is not possible to use INFO in these cases. > >>>> > >>>> The group will produce: > >>>> > >>>> - A problem statement and requirements document for > >>> implementing a SIP > >>>> call control UUI mechanism > >>>> > >>>> - A specification of the SIP extension to best meet those > >>> requirements. > >>>> Goals and Milestones > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>> > >>>> Sep 10 - Problem statement and requirements document to IESG > >>>> (Informational) > >>>> Mar 11 - SIP call control UUI specification to IESG (PS)=20 > >>>> _______________________________________________ > >>>> IETF-Announce mailing list > >>>> IETF-Announce@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ietf-announce > >>> > >>> Cullen Jennings > >>> For corporate legal information go to: > >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > = From dromasca@avaya.com Wed Jun 30 03:43:25 2010 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 B569B3A6A90; Wed, 30 Jun 2010 03:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.626, 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 HU4M7IWFVXQQ; Wed, 30 Jun 2010 03:43:25 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id B98D23A6818; Wed, 30 Jun 2010 03:43:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,511,1272859200"; d="scan'208";a="23043012" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 30 Jun 2010 06:43:35 -0400 X-IronPort-AV: E=Sophos;i="4.53,511,1272859200"; d="scan'208";a="477304417" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 Jun 2010 06:42:59 -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, 30 Jun 2010 12:42:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsW6MCmpYN4qtxmRxeuIeMgY1MYMwBV08iw References: From: "Romascanu, Dan (Dan)" To: "Mary Barnes" , "DISPATCH" Cc: IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 10:43:26 -0000 > The VIPR WG will address this problem by developing a peer to=20 > peer based approach to finding domains that claim to be=20 > responsible for a given phone number and validation protocols=20 > to ensure a reasonable likelihood that a given domain=20 > actually is responsible for the phone number.=20 Hi, Clarification question. What exactly means 'peer to peer based approach' and what kind of approaches are excluded by having this in the charter. Does 'approach' mean solution? If so why does a specific type of solution need to be agreed in the charter, while all we have at hand at this point are individual contribution I-Ds that describe the 'problem statement and some possible starting points for solutions'? Thanks and Regards, Dan > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Monday, June 28, 2010 8:38 PM > To: DISPATCH > Subject: [dispatch] VIPR - proposed charter version 3 >=20 From dromasca@avaya.com Wed Jun 30 03:48:13 2010 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 6CDD23A6A8B; Wed, 30 Jun 2010 03:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVb+e1qeHZnl; Wed, 30 Jun 2010 03:48:06 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DFE5A3A6A7A; Wed, 30 Jun 2010 03:48:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,511,1272859200"; d="scan'208";a="195900898" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Jun 2010 06:48:15 -0400 X-IronPort-AV: E=Sophos;i="4.53,511,1272859200"; d="scan'208";a="487617854" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Jun 2010 06:48:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Jun 2010 12:47:57 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsW68RjeZfr39y7SoispI2QiC93zwBVYQCw References: From: "Romascanu, Dan (Dan)" To: "Mary Barnes" , "DRAGE, Keith (Keith)" Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 10:48:14 -0000 Hi Mary, I also think that listing the deliverables should be independent from = mentioning the existing initial contributions. The existing = contributions could be listed as well, but they should not preclude = other contributions on the same items after the WG is formed.=20 Regards, Dan > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Monday, June 28, 2010 9:00 PM > To: DRAGE, Keith (Keith) > Cc: DISPATCH > Subject: Re: [dispatch] VIPR - proposed charter version 3 >=20 > Hi Keith, >=20 > That's a valid concern and we can rewrite the deliverables as=20 > functional descriptions as we have done for other WG charters=20 > even in cases where documents existed (e.g., overload). The=20 > current text is trying to say that these documents map to=20 > deliverables and can be used as WG documents, although as it=20 > notes these should be considered starting points (i.e., it's=20 > understood the proposed WG has change control), but certainly=20 > the current text is somewhat misleading. >=20 > Thanks, > Mary. >=20 > On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith)=20 > wrote: > > I have a major issue with including "which shall form the=20 > bases of the WG documents" into the charter. To me this is=20 > confusing the charter discussion with the working group that=20 > might eventually result deciding what its deliverables, and=20 > their contents, shall be. > > > > regards > > > > Keith > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 6:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > >> Hi all, > >> > >> Below, please find version 3 of the VIPR proposed charter. > >> It's been updated to reflect ML feedback, in particular=20 > VAP has been=20 > >> added and clarifications have been made with regards to impacts=20 > >> (i.e., none) on existing PSTN interfaces. > >> > >> Regards, > >> Mary > >> (DISPATCH WG co-chair) > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> VIPR Charter Proposal (Version 3) > >> > >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) > >> > >> There are two globally deployed address spaces for communications=20 > >> used by more than a billion people daily - phone numbers and DNS=20 > >> rooted address such as web servers and email addresses. The=20 > >> inter-domain signaling design of SIP is primarily designed=20 > for email=20 > >> style addresses yet a large percentage of SIP deployments=20 > mostly use=20 > >> phone numbers for identifying users. The goal of this=20 > working group=20 > >> is to enable inter-domain communications over the the=20 > Internet, using=20 > >> protocols such as SIP, while still allowing people to use phone=20 > >> numbers to identify the person with whom they wish to communicate. > >> > >> The VIPR WG will address this problem by developing a peer to peer=20 > >> based approach to finding domains that claim to be=20 > responsible for a=20 > >> given phone number and validation protocols to ensure a reasonable=20 > >> likelihood that a given domain actually is responsible for=20 > the phone=20 > >> number. In this context, "responsible" means an administrative=20 > >> domain, which is at least one of the domains, to which a=20 > PSTN call to=20 > >> this phone number would be routed. Once the domain responsible for=20 > >> the phone number is found, existing protocols, such as SIP, can be=20 > >> used for inter-domain communications. > >> > >> Some validation protocols may be based on knowledge=20 > gathered around a=20 > >> PSTN call; for example, the ability to prove a call was=20 > received over=20 > >> the PSTN based on start and stop times. > >> Other validation schemes, such as examining fingerprints or=20 > >> watermarking of PSTN media to show that a domain received a=20 > >> particular PSTN phone call, may also be considered by the working=20 > >> group. This validation will be accomplished using publicly=20 > available=20 > >> open interfaces to the PSTN, so the validation can be performed by=20 > >> any domain wishing to participate. =A0The WG will select and=20 > >> standardize at least one validation scheme. > >> > >> The validation mechanism requires a domain to gather and maintain=20 > >> information related to PSTN calls. =A0This information is=20 > used by call=20 > >> agents such as phones, SBCs and IP PBXs to route calls. =A0 > The WG will=20 > >> define a client-server protocol between these call agents and the=20 > >> entity within a domain that maintains the information. > >> > >> To help mitigate SPAM issues when using SIP between=20 > domains, the WG=20 > >> will define a mechanism to enable one domain to check that=20 > incoming=20 > >> SIP messages are coming from a validated phone number. =A0A phone=20 > >> number is considered validated if it is coming from a=20 > domain to which=20 > >> the calling domain had previously successfully placed a=20 > PSTN call. =A0 > >> The working group will define new SIP headers and option tags, as=20 > >> necessary, to enable this. > >> > >> The essential characteristic of VIPR is establishing=20 > authentication=20 > >> by PSTN reachability when it is not possible to use a direct=20 > >> reference to ENUM databases or other direct assertions of=20 > PSTN number=20 > >> ownership. Elements such as public ENUM easily coexist=20 > with VIPR but=20 > >> no direct interaction with ENUM will be required. =A0The=20 > solution set=20 > >> defined by this WG will be incrementally deployable using only=20 > >> existing interfaces to the PSTN. =A0No changes will be required to=20 > >> existing PSTN capabilities, no new database access is=20 > needed nor is=20 > >> any new support from PSTN service providers required. > >> > >> The problem statement and some possible starting points=20 > for solutions=20 > >> are further discussed in the following internet drafts which shall=20 > >> form the bases of the WG documents: > >> > >> draft-rosenberg-dispatch-vipr-overview > >> draft-rosenberg-dispatch-vipr-reload-usage > >> draft-rosenberg-dispatch-vipr-pvp > >> draft-rosenberg-dispatch-vipr-sip-antispam > >> draft-rosenberg-dispatch-vipr-vap > >> > >> The working group will carefully coordinate with the=20 > security area,=20 > >> O&M area, as well as the appropriate RAI WGs such as sipcore and=20 > >> p2psip. > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From keith.drage@alcatel-lucent.com Wed Jun 30 04:57:40 2010 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 B885A3A68E3 for ; Wed, 30 Jun 2010 04:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[AWL=1.232, 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 LUzdm3xfBJxh for ; Wed, 30 Jun 2010 04:57:39 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 31A443A68DA for ; Wed, 30 Jun 2010 04:57:38 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5UBvX5i023506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 Jun 2010 13:57:46 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 30 Jun 2010 13:57:39 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes Date: Wed, 30 Jun 2010 13:57:32 +0200 Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsW68aFVkigk7ZdTtGETvPVzGv2rQBX3Klg 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 11:57:40 -0000 It is not clear whether you are proposing a rewrite that removes the names = of the deliverables, and therefore removes the problem that way, or not. Wi= thout seeing words, I cannot comment on the specifics of that. In any case, the minimum change to me is to remove the words indicated. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Monday, June 28, 2010 7:00 PM > To: DRAGE, Keith (Keith) > Cc: DISPATCH > Subject: Re: [dispatch] VIPR - proposed charter version 3 >=20 > Hi Keith, >=20 > That's a valid concern and we can rewrite the deliverables as=20 > functional descriptions as we have done for other WG charters=20 > even in cases where documents existed (e.g., overload). The=20 > current text is trying to say that these documents map to=20 > deliverables and can be used as WG documents, although as it=20 > notes these should be considered starting points (i.e., it's=20 > understood the proposed WG has change control), but certainly=20 > the current text is somewhat misleading. >=20 > Thanks, > Mary. >=20 > On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith)=20 > wrote: > > I have a major issue with including "which shall form the=20 > bases of the WG documents" into the charter. To me this is=20 > confusing the charter discussion with the working group that=20 > might eventually result deciding what its deliverables, and=20 > their contents, shall be. > > > > regards > > > > Keith > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 6:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > >> Hi all, > >> > >> Below, please find version 3 of the VIPR proposed charter. > >> It's been updated to reflect ML feedback, in particular=20 > VAP has been=20 > >> added and clarifications have been made with regards to impacts=20 > >> (i.e., none) on existing PSTN interfaces. > >> > >> Regards, > >> Mary > >> (DISPATCH WG co-chair) > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> VIPR Charter Proposal (Version 3) > >> > >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) > >> > >> There are two globally deployed address spaces for communications=20 > >> used by more than a billion people daily - phone numbers and DNS=20 > >> rooted address such as web servers and email addresses. The=20 > >> inter-domain signaling design of SIP is primarily designed=20 > for email=20 > >> style addresses yet a large percentage of SIP deployments=20 > mostly use=20 > >> phone numbers for identifying users. The goal of this=20 > working group=20 > >> is to enable inter-domain communications over the the=20 > Internet, using=20 > >> protocols such as SIP, while still allowing people to use phone=20 > >> numbers to identify the person with whom they wish to communicate. > >> > >> The VIPR WG will address this problem by developing a peer to peer=20 > >> based approach to finding domains that claim to be=20 > responsible for a=20 > >> given phone number and validation protocols to ensure a reasonable=20 > >> likelihood that a given domain actually is responsible for=20 > the phone=20 > >> number. In this context, "responsible" means an administrative=20 > >> domain, which is at least one of the domains, to which a=20 > PSTN call to=20 > >> this phone number would be routed. Once the domain responsible for=20 > >> the phone number is found, existing protocols, such as SIP, can be=20 > >> used for inter-domain communications. > >> > >> Some validation protocols may be based on knowledge=20 > gathered around a=20 > >> PSTN call; for example, the ability to prove a call was=20 > received over=20 > >> the PSTN based on start and stop times. > >> Other validation schemes, such as examining fingerprints or=20 > >> watermarking of PSTN media to show that a domain received a=20 > >> particular PSTN phone call, may also be considered by the working=20 > >> group. This validation will be accomplished using publicly=20 > available=20 > >> open interfaces to the PSTN, so the validation can be performed by=20 > >> any domain wishing to participate. =A0The WG will select and=20 > >> standardize at least one validation scheme. > >> > >> The validation mechanism requires a domain to gather and maintain=20 > >> information related to PSTN calls. =A0This information is=20 > used by call=20 > >> agents such as phones, SBCs and IP PBXs to route calls. =A0 > The WG will=20 > >> define a client-server protocol between these call agents and the=20 > >> entity within a domain that maintains the information. > >> > >> To help mitigate SPAM issues when using SIP between=20 > domains, the WG=20 > >> will define a mechanism to enable one domain to check that=20 > incoming=20 > >> SIP messages are coming from a validated phone number. =A0A phone=20 > >> number is considered validated if it is coming from a=20 > domain to which=20 > >> the calling domain had previously successfully placed a=20 > PSTN call. =A0 > >> The working group will define new SIP headers and option tags, as=20 > >> necessary, to enable this. > >> > >> The essential characteristic of VIPR is establishing=20 > authentication=20 > >> by PSTN reachability when it is not possible to use a direct=20 > >> reference to ENUM databases or other direct assertions of=20 > PSTN number=20 > >> ownership. Elements such as public ENUM easily coexist=20 > with VIPR but=20 > >> no direct interaction with ENUM will be required. =A0The=20 > solution set=20 > >> defined by this WG will be incrementally deployable using only=20 > >> existing interfaces to the PSTN. =A0No changes will be required to=20 > >> existing PSTN capabilities, no new database access is=20 > needed nor is=20 > >> any new support from PSTN service providers required. > >> > >> The problem statement and some possible starting points=20 > for solutions=20 > >> are further discussed in the following internet drafts which shall=20 > >> form the bases of the WG documents: > >> > >> draft-rosenberg-dispatch-vipr-overview > >> draft-rosenberg-dispatch-vipr-reload-usage > >> draft-rosenberg-dispatch-vipr-pvp > >> draft-rosenberg-dispatch-vipr-sip-antispam > >> draft-rosenberg-dispatch-vipr-vap > >> > >> The working group will carefully coordinate with the=20 > security area,=20 > >> O&M area, as well as the appropriate RAI WGs such as sipcore and=20 > >> p2psip. > >> _______________________________________________ > >> 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 gonzalo.camarillo@ericsson.com Wed Jun 30 04:59:29 2010 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 B7C113A69B2 for ; Wed, 30 Jun 2010 04:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y47gQDr1ZfkH for ; Wed, 30 Jun 2010 04:59:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B23593A6985 for ; Wed, 30 Jun 2010 04:59:28 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-fd-4c2b31aa898b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 61.0E.19600.AA13B2C4; Wed, 30 Jun 2010 13:59:39 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 13:59:22 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jun 2010 13:59:22 +0200 Message-ID: <4C2B319A.8020004@ericsson.com> Date: Wed, 30 Jun 2010 14:59:22 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2010 11:59:22.0525 (UTC) FILETIME=[ADA7A4D0:01CB184B] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Community reviews 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, 30 Jun 2010 11:59:29 -0000 Hi, as you know, the IETF processes include community reviews of drafts, WG charters, etc. These reviews are typically announced on the IETF announce list. Discussions are supposed to take place on both the IETF general discussion list and the WG list. It is important that messages are sent to both lists because there are reviewers that are not subscribed to the WG list (e.g., ADs from other areas) and WG contributors that are not subscribed (and do not want to be for a number of reasons) to the IETF general discussion list. So far, I have been taking care of forwarding emails that are only sent to one of the lists, but, as you can imagine, it would be far better if people took care of this themselves when sending their emails. The thing is that IETF LCs on drafts are generally automatically sent to both lists. However, the latest requests to review charter proposals have only been sent to the IETF general discussion list. We will try and make sure that future requests to review charter proposals coming from DISPATCH are also sent to the DISPATCH list... in the meantime, please to as suggested above. Thanks, Gonzalo From mary.ietf.barnes@gmail.com Wed Jun 30 08:23:58 2010 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 7EBC83A684A; Wed, 30 Jun 2010 08:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 UzdYQJmC947n; Wed, 30 Jun 2010 08:23:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 98EF23A6A3B; Wed, 30 Jun 2010 08:23:54 -0700 (PDT) Received: by gyh3 with SMTP id 3so515714gyh.31 for ; Wed, 30 Jun 2010 08:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0dzUnI6Grc07SuxGRSrHXCrZseTsfsVYcy/rMjYS6Vc=; b=mcf84Y+Sg+hTwmkt7OZe3IZmAya+YIfeReTbfcL2ukf9VsLmTkUZ5tu778XGcdtNNN YbhwinUCsAvrYaVoEg9svSChgr5h/vl6poSQho4mb9jSxQgnsAyMknZm5Hr3lPATPa+7 lTsiUU2USMp3tuLG4As4o75my/33y2IW9hz0s= 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=kccaWG8771zs92CRgHbaNQiszfpHUCR6w7LV9jOLlz7xad+KszHR3I7BbasPAzjEs9 wTxejFK7xV9dISYUupHzHreOUmodsG1FZCcL+XFlrj4cMobBUVdPnJbTozDhiXNX7mGN NmHyZnSRI+tW3jJDMi4dIPJlWddT7FqeZvpuA= MIME-Version: 1.0 Received: by 10.102.226.11 with SMTP id y11mr3154865mug.54.1277911441796; Wed, 30 Jun 2010 08:24:01 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Wed, 30 Jun 2010 08:24:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jun 2010 10:24:01 -0500 Message-ID: From: Mary Barnes To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 15:23:58 -0000 Hi Dan, The term peer to peer is intended to exclude mechanisms that would use a central repository for the information: This was discussed in an earlier thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html In one sense it is a solution, however, in another sense it is reusing SIP related functionality defined in RAI and thus is in a similar vein as specifying the use of SIP in a charter. Thanks, Mary. On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) wrote: >> The VIPR WG will address this problem by developing a peer to >> peer based approach to finding domains that claim to be >> responsible for a given phone number and validation protocols >> to ensure a reasonable likelihood that a given domain >> actually is responsible for the phone number. > > Hi, > > Clarification question. What exactly means 'peer to peer based approach' > and what kind of approaches are excluded by having this in the charter. > Does 'approach' mean solution? If so why does a specific type of > solution need to be agreed in the charter, while all we have at hand at > this point are individual contribution I-Ds that describe the 'problem > statement and some possible starting points for solutions'? > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> Sent: Monday, June 28, 2010 8:38 PM >> To: DISPATCH >> Subject: [dispatch] VIPR - proposed charter version 3 >> > From mary.ietf.barnes@gmail.com Wed Jun 30 08:24:46 2010 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 C04193A6848; Wed, 30 Jun 2010 08:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, 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 tBdAGU2joK8W; Wed, 30 Jun 2010 08:24:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 158153A6826; Wed, 30 Jun 2010 08:24:45 -0700 (PDT) Received: by yxm8 with SMTP id 8so128363yxm.31 for ; Wed, 30 Jun 2010 08:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A26SadK+DNY8SJBBwiyHz0pYvev6MwR47LwLu6X3oV8=; b=C4rfjxxxcJqb8EJhetm/gMVr0O+VaPlLtQKPYvtYcT4oV3h3SKz2pPP0nMl4Lphaiy jo6OtEVjJr2BZEwFwCUJqsbmkfN04EcU6ssDwfLjg9cUEav4OHjmupKMATqug5sWgJp8 j9M7i+/osjoR7eLVZ+U8imwJeXsewuKtcPhxE= 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:content-transfer-encoding; b=duy22aSSGHOaPJllpKEIv1g/4BeU66kVC2eUC70jpMKhp48ewsOtcmb0wxEka9GwD1 rUUytsZvk19odcCOqg0XcrJk5mLFXtXlFAsHj7PYZ23uTWmwHKeA612x2ArfBd8/eLrK JtevdK+lpPjYRb22jVGENJdFnLL5avz2COcVE= MIME-Version: 1.0 Received: by 10.102.211.40 with SMTP id j40mr3182653mug.69.1277911491648; Wed, 30 Jun 2010 08:24:51 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Wed, 30 Jun 2010 08:24:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jun 2010 10:24:51 -0500 Message-ID: From: Mary Barnes To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH , "DRAGE, Keith \(Keith\)" , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 15:24:46 -0000 Agreed - I will make that change in the version 4 of the charter. Thanks, Mary. 2010/6/30 Romascanu, Dan (Dan) : > Hi Mary, > > I also think that listing the deliverables should be independent from men= tioning the existing initial contributions. The existing contributions coul= d be listed as well, but they should not preclude other contributions on th= e same items after the WG is formed. > > Regards, > > Dan > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> Sent: Monday, June 28, 2010 9:00 PM >> To: DRAGE, Keith (Keith) >> Cc: DISPATCH >> Subject: Re: [dispatch] VIPR - proposed charter version 3 >> >> Hi Keith, >> >> That's a valid concern and we can rewrite the deliverables as >> functional descriptions as we have done for other WG charters >> even in cases where documents existed (e.g., overload). =A0The >> current text is trying to say that these documents map to >> deliverables and can be used as WG documents, although as it >> notes these should be considered starting points (i.e., it's >> understood the proposed WG has change control), but certainly >> the current text is somewhat misleading. >> >> Thanks, >> Mary. >> >> On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith) >> wrote: >> > I have a major issue with including "which shall form the >> bases of the WG documents" into the charter. To me this is >> confusing the charter discussion with the working group that >> might eventually result deciding what its deliverables, and >> their contents, shall be. >> > >> > regards >> > >> > Keith >> > >> >> -----Original Message----- >> >> From: dispatch-bounces@ietf.org >> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> >> Sent: Monday, June 28, 2010 6:38 PM >> >> To: DISPATCH >> >> Subject: [dispatch] VIPR - proposed charter version 3 >> >> >> >> Hi all, >> >> >> >> Below, please find version 3 of the VIPR proposed charter. >> >> It's been updated to reflect ML feedback, in particular >> VAP has been >> >> added and clarifications have been made with regards to impacts >> >> (i.e., none) on existing PSTN interfaces. >> >> >> >> Regards, >> >> Mary >> >> (DISPATCH WG co-chair) >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> VIPR Charter Proposal (Version 3) >> >> >> >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) >> >> >> >> There are two globally deployed address spaces for communications >> >> used by more than a billion people daily - phone numbers and DNS >> >> rooted address such as web servers and email addresses. The >> >> inter-domain signaling design of SIP is primarily designed >> for email >> >> style addresses yet a large percentage of SIP deployments >> mostly use >> >> phone numbers for identifying users. The goal of this >> working group >> >> is to enable inter-domain communications over the the >> Internet, using >> >> protocols such as SIP, while still allowing people to use phone >> >> numbers to identify the person with whom they wish to communicate. >> >> >> >> The VIPR WG will address this problem by developing a peer to peer >> >> based approach to finding domains that claim to be >> responsible for a >> >> given phone number and validation protocols to ensure a reasonable >> >> likelihood that a given domain actually is responsible for >> the phone >> >> number. In this context, "responsible" means an administrative >> >> domain, which is at least one of the domains, to which a >> PSTN call to >> >> this phone number would be routed. Once the domain responsible for >> >> the phone number is found, existing protocols, such as SIP, can be >> >> used for inter-domain communications. >> >> >> >> Some validation protocols may be based on knowledge >> gathered around a >> >> PSTN call; for example, the ability to prove a call was >> received over >> >> the PSTN based on start and stop times. >> >> Other validation schemes, such as examining fingerprints or >> >> watermarking of PSTN media to show that a domain received a >> >> particular PSTN phone call, may also be considered by the working >> >> group. This validation will be accomplished using publicly >> available >> >> open interfaces to the PSTN, so the validation can be performed by >> >> any domain wishing to participate. =A0The WG will select and >> >> standardize at least one validation scheme. >> >> >> >> The validation mechanism requires a domain to gather and maintain >> >> information related to PSTN calls. =A0This information is >> used by call >> >> agents such as phones, SBCs and IP PBXs to route calls. >> The WG will >> >> define a client-server protocol between these call agents and the >> >> entity within a domain that maintains the information. >> >> >> >> To help mitigate SPAM issues when using SIP between >> domains, the WG >> >> will define a mechanism to enable one domain to check that >> incoming >> >> SIP messages are coming from a validated phone number. =A0A phone >> >> number is considered validated if it is coming from a >> domain to which >> >> the calling domain had previously successfully placed a >> PSTN call. >> >> The working group will define new SIP headers and option tags, as >> >> necessary, to enable this. >> >> >> >> The essential characteristic of VIPR is establishing >> authentication >> >> by PSTN reachability when it is not possible to use a direct >> >> reference to ENUM databases or other direct assertions of >> PSTN number >> >> ownership. Elements such as public ENUM easily coexist >> with VIPR but >> >> no direct interaction with ENUM will be required. =A0The >> solution set >> >> defined by this WG will be incrementally deployable using only >> >> existing interfaces to the PSTN. =A0No changes will be required to >> >> existing PSTN capabilities, no new database access is >> needed nor is >> >> any new support from PSTN service providers required. >> >> >> >> The problem statement and some possible starting points >> for solutions >> >> are further discussed in the following internet drafts which shall >> >> form the bases of the WG documents: >> >> >> >> draft-rosenberg-dispatch-vipr-overview >> >> draft-rosenberg-dispatch-vipr-reload-usage >> >> draft-rosenberg-dispatch-vipr-pvp >> >> draft-rosenberg-dispatch-vipr-sip-antispam >> >> draft-rosenberg-dispatch-vipr-vap >> >> >> >> The working group will carefully coordinate with the >> security area, >> >> O&M area, as well as the appropriate RAI WGs such as sipcore and >> >> p2psip. >> >> _______________________________________________ >> >> 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.ietf.barnes@gmail.com Wed Jun 30 08:29:51 2010 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 D07C53A68DD for ; Wed, 30 Jun 2010 08:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 sXcDP9VI7G4D for ; Wed, 30 Jun 2010 08:29:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EED553A6886 for ; Wed, 30 Jun 2010 08:29:49 -0700 (PDT) Received: by iwn40 with SMTP id 40so1016761iwn.31 for ; Wed, 30 Jun 2010 08:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UtDE3TKlWc5deCEryFIqDZPCIPn5FFdGM897aEf/m5g=; b=MdKVh3xDyi5EVfuPduJuQllemp2CViX6cgBWFnXSY5+aNLsXTaEbSPbmKtzFZx5QFT YKhx/ZLLDLzoGtHmHo6+MqUrFkApGcPw9FH83PQT+SHooOElA4ZhdOfv4j0jKQz9q/hp x1GAHFXoPkla1SWRYFgPSZuukEwEjlc3ZUJDU= 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:content-transfer-encoding; b=x3WhCOMBQT2iCKBIMCkiXaWux0ovTSgIQ0sS7zNm8ncf976eZuTSZlRCqFo/zLpcaT 9AyN/ZhhtJI0sy3G9UlP8OB7QjAKbAZL2T5Mc0ZFu3vSDl+SIAojHg979wTN+fZnBT2R wctPm958TzgCJz7/dbSNO7aWUeP7nUarwhSvU= MIME-Version: 1.0 Received: by 10.231.119.71 with SMTP id y7mr8461701ibq.158.1277911800743; Wed, 30 Jun 2010 08:30:00 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Wed, 30 Jun 2010 08:30:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jun 2010 10:30:00 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 15:29:51 -0000 I will remove both the list of draft names and the paragraph that introduces those and replace it with text describing deliverables as is typically done for charters. At this point, I think everyone is well aware of the related documents. Thanks, Mary. On Wed, Jun 30, 2010 at 6:57 AM, DRAGE, Keith (Keith) wrote: > It is not clear whether you are proposing a rewrite that removes the name= s of the deliverables, and therefore removes the problem that way, or not. = Without seeing words, I cannot comment on the specifics of that. > > In any case, the minimum change to me is to remove the words indicated. > > regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> Sent: Monday, June 28, 2010 7:00 PM >> To: DRAGE, Keith (Keith) >> Cc: DISPATCH >> Subject: Re: [dispatch] VIPR - proposed charter version 3 >> >> Hi Keith, >> >> That's a valid concern and we can rewrite the deliverables as >> functional descriptions as we have done for other WG charters >> even in cases where documents existed (e.g., overload). =A0The >> current text is trying to say that these documents map to >> deliverables and can be used as WG documents, although as it >> notes these should be considered starting points (i.e., it's >> understood the proposed WG has change control), but certainly >> the current text is somewhat misleading. >> >> Thanks, >> Mary. >> >> On Mon, Jun 28, 2010 at 12:43 PM, DRAGE, Keith (Keith) >> wrote: >> > I have a major issue with including "which shall form the >> bases of the WG documents" into the charter. To me this is >> confusing the charter discussion with the working group that >> might eventually result deciding what its deliverables, and >> their contents, shall be. >> > >> > regards >> > >> > Keith >> > >> >> -----Original Message----- >> >> From: dispatch-bounces@ietf.org >> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> >> Sent: Monday, June 28, 2010 6:38 PM >> >> To: DISPATCH >> >> Subject: [dispatch] VIPR - proposed charter version 3 >> >> >> >> Hi all, >> >> >> >> Below, please find version 3 of the VIPR proposed charter. >> >> It's been updated to reflect ML feedback, in particular >> VAP has been >> >> added and clarifications have been made with regards to impacts >> >> (i.e., none) on existing PSTN interfaces. >> >> >> >> Regards, >> >> Mary >> >> (DISPATCH WG co-chair) >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> VIPR Charter Proposal (Version 3) >> >> >> >> WG Name: =A0Verification Involving PSTN Reachability (VIPR) >> >> >> >> There are two globally deployed address spaces for communications >> >> used by more than a billion people daily - phone numbers and DNS >> >> rooted address such as web servers and email addresses. The >> >> inter-domain signaling design of SIP is primarily designed >> for email >> >> style addresses yet a large percentage of SIP deployments >> mostly use >> >> phone numbers for identifying users. The goal of this >> working group >> >> is to enable inter-domain communications over the the >> Internet, using >> >> protocols such as SIP, while still allowing people to use phone >> >> numbers to identify the person with whom they wish to communicate. >> >> >> >> The VIPR WG will address this problem by developing a peer to peer >> >> based approach to finding domains that claim to be >> responsible for a >> >> given phone number and validation protocols to ensure a reasonable >> >> likelihood that a given domain actually is responsible for >> the phone >> >> number. In this context, "responsible" means an administrative >> >> domain, which is at least one of the domains, to which a >> PSTN call to >> >> this phone number would be routed. Once the domain responsible for >> >> the phone number is found, existing protocols, such as SIP, can be >> >> used for inter-domain communications. >> >> >> >> Some validation protocols may be based on knowledge >> gathered around a >> >> PSTN call; for example, the ability to prove a call was >> received over >> >> the PSTN based on start and stop times. >> >> Other validation schemes, such as examining fingerprints or >> >> watermarking of PSTN media to show that a domain received a >> >> particular PSTN phone call, may also be considered by the working >> >> group. This validation will be accomplished using publicly >> available >> >> open interfaces to the PSTN, so the validation can be performed by >> >> any domain wishing to participate. =A0The WG will select and >> >> standardize at least one validation scheme. >> >> >> >> The validation mechanism requires a domain to gather and maintain >> >> information related to PSTN calls. =A0This information is >> used by call >> >> agents such as phones, SBCs and IP PBXs to route calls. >> The WG will >> >> define a client-server protocol between these call agents and the >> >> entity within a domain that maintains the information. >> >> >> >> To help mitigate SPAM issues when using SIP between >> domains, the WG >> >> will define a mechanism to enable one domain to check that >> incoming >> >> SIP messages are coming from a validated phone number. =A0A phone >> >> number is considered validated if it is coming from a >> domain to which >> >> the calling domain had previously successfully placed a >> PSTN call. >> >> The working group will define new SIP headers and option tags, as >> >> necessary, to enable this. >> >> >> >> The essential characteristic of VIPR is establishing >> authentication >> >> by PSTN reachability when it is not possible to use a direct >> >> reference to ENUM databases or other direct assertions of >> PSTN number >> >> ownership. Elements such as public ENUM easily coexist >> with VIPR but >> >> no direct interaction with ENUM will be required. =A0The >> solution set >> >> defined by this WG will be incrementally deployable using only >> >> existing interfaces to the PSTN. =A0No changes will be required to >> >> existing PSTN capabilities, no new database access is >> needed nor is >> >> any new support from PSTN service providers required. >> >> >> >> The problem statement and some possible starting points >> for solutions >> >> are further discussed in the following internet drafts which shall >> >> form the bases of the WG documents: >> >> >> >> draft-rosenberg-dispatch-vipr-overview >> >> draft-rosenberg-dispatch-vipr-reload-usage >> >> draft-rosenberg-dispatch-vipr-pvp >> >> draft-rosenberg-dispatch-vipr-sip-antispam >> >> draft-rosenberg-dispatch-vipr-vap >> >> >> >> The working group will carefully coordinate with the >> security area, >> >> O&M area, as well as the appropriate RAI WGs such as sipcore and >> >> p2psip. >> >> _______________________________________________ >> >> 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 dromasca@avaya.com Wed Jun 30 08:33:25 2010 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 4FE413A67E9; Wed, 30 Jun 2010 08:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.617, 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 HiTVgn80Qhyy; Wed, 30 Jun 2010 08:33:22 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DEF573A6A15; Wed, 30 Jun 2010 08:33:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,513,1272859200"; d="scan'208";a="195953642" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Jun 2010 11:33:27 -0400 X-IronPort-AV: E=Sophos;i="4.53,513,1272859200"; d="scan'208";a="477417872" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 Jun 2010 11:33:26 -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, 30 Jun 2010 17:33:24 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsYaEYFoTRFDNeFTEGpj7QmoZE2ywAAL8OA References: From: "Romascanu, Dan (Dan)" To: "Mary Barnes" Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 15:33:25 -0000 It looks to me that one can imagine 'centralized' solutions which are also based on reusing SIP related functionality developed in RAI. I would rather not close such an option and allow the WG a window of opportunity in which alternate solutions that could meet the same goals can be presented. =20 Dan > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: Wednesday, June 30, 2010 6:24 PM > To: Romascanu, Dan (Dan) > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 >=20 > Hi Dan, >=20 > The term peer to peer is intended to exclude mechanisms that=20 > would use a central repository for the information: This was=20 > discussed in an earlier thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html >=20 > In one sense it is a solution, however, in another sense it=20 > is reusing SIP related functionality defined in RAI and thus=20 > is in a similar vein as specifying the use of SIP in a charter. >=20 > Thanks, > Mary. >=20 > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan)=20 > wrote: > >> The VIPR WG will address this problem by developing a peer to peer=20 > >> based approach to finding domains that claim to be=20 > responsible for a=20 > >> given phone number and validation protocols to ensure a reasonable=20 > >> likelihood that a given domain actually is responsible for=20 > the phone=20 > >> number. > > > > Hi, > > > > Clarification question. What exactly means 'peer to peer=20 > based approach' > > and what kind of approaches are excluded by having this in=20 > the charter. > > Does 'approach' mean solution? If so why does a specific type of=20 > > solution need to be agreed in the charter, while all we=20 > have at hand=20 > > at this point are individual contribution I-Ds that describe the=20 > > 'problem statement and some possible starting points for solutions'? > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 8:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > > >=20 From mary.ietf.barnes@gmail.com Wed Jun 30 08:47:12 2010 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 45CCB3A684A; Wed, 30 Jun 2010 08:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 80NaEq93brQ9; Wed, 30 Jun 2010 08:47:11 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 0776D3A6838; Wed, 30 Jun 2010 08:47:10 -0700 (PDT) Received: by gyh3 with SMTP id 3so538900gyh.31 for ; Wed, 30 Jun 2010 08:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=APScbgy4oeDXCxxpjmY9QJG4HwXIj8/fEnM+Zj2UUFw=; b=vwhaLr/lCYAsgZpTw4JvCRv4TSpx2QYHK4y3APmpxnth+2puFbRSJNDYwQpvvAb9HW XFLUOdd/URN7vRTwaslP7ID4clk42zkj8gVDJ5ZuGpCgOW+y7JC14QJ80hSRExffhVah YkMZ8SGB7w4EwazO+2HxRJaPZD3bJVaaZkAo4= 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:content-transfer-encoding; b=qh0QeAYEgUIDpM3moPGkj5H+yoSFnF0NRTKWNO125VuPmMy2JViI/m2eYdOiionJGL YvJvbIiF51yYh75lftuY78ylSKML5DcKzXbdT3A6tqGCYoIkB45P9VHvCTi/XgMkOBtj yCdStSnGd+sbo1D4TjXPVarGAbhPUS1bIHGF8= MIME-Version: 1.0 Received: by 10.102.226.11 with SMTP id y11mr3211782mug.54.1277912835496; Wed, 30 Jun 2010 08:47:15 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Wed, 30 Jun 2010 08:47:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Jun 2010 10:47:15 -0500 Message-ID: From: Mary Barnes To: "Romascanu, Dan (Dan)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 15:47:12 -0000 Hi Dan, One of the starting points for this work is that more centralized solutions to this problem have been defined (and implemented), yet they have not been successful. Per one of Christer's earllier comments, we will add some text with reference to such and thus substantiate why this group is focusing on a p2p based solution. Thanks, Mary. On Wed, Jun 30, 2010 at 10:33 AM, Romascanu, Dan (Dan) wrote: > It looks to me that one can imagine 'centralized' solutions which are > also based on reusing SIP related functionality developed in RAI. I > would rather not close such an option and allow the WG a window of > opportunity in which alternate solutions that could meet the same goals > can be presented. > > Dan > > >> -----Original Message----- >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> Sent: Wednesday, June 30, 2010 6:24 PM >> To: Romascanu, Dan (Dan) >> Cc: DISPATCH; IETF-Discussion list >> Subject: Re: [dispatch] VIPR - proposed charter version 3 >> >> Hi Dan, >> >> The term peer to peer is intended to exclude mechanisms that >> would use a central repository for the information: =A0This was >> discussed in an earlier thread: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html >> >> In one sense it is a solution, however, in another sense it >> is reusing SIP related functionality defined in RAI and thus >> is in a similar vein as specifying the use of SIP in a charter. >> >> Thanks, >> Mary. >> >> On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) >> wrote: >> >> The VIPR WG will address this problem by developing a peer to peer >> >> based approach to finding domains that claim to be >> responsible for a >> >> given phone number and validation protocols to ensure a reasonable >> >> likelihood that a given domain actually is responsible for >> the phone >> >> number. >> > >> > Hi, >> > >> > Clarification question. What exactly means 'peer to peer >> based approach' >> > and what kind of approaches are excluded by having this in >> the charter. >> > Does 'approach' mean solution? If so why does a specific type of >> > solution need to be agreed in the charter, while all we >> have at hand >> > at this point are individual contribution I-Ds that describe the >> > 'problem statement and some possible starting points for solutions'? >> > >> > Thanks and Regards, >> > >> > Dan >> > >> > >> >> -----Original Message----- >> >> From: dispatch-bounces@ietf.org >> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> >> Sent: Monday, June 28, 2010 8:38 PM >> >> To: DISPATCH >> >> Subject: [dispatch] VIPR - proposed charter version 3 >> >> >> > >> > From ron.even.tlv@gmail.com Wed Jun 30 09:04:07 2010 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 6BE923A6A3B; Wed, 30 Jun 2010 09:04:07 -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 DvMm+IHA00Tn; Wed, 30 Jun 2010 09:04:06 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 624763A6A1D; Wed, 30 Jun 2010 09:04:06 -0700 (PDT) Received: by pvd12 with SMTP id 12so550205pvd.31 for ; Wed, 30 Jun 2010 09:04:15 -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=11CToXs2YR8w0NUseg8mmx8mQTa5gRYBVZ80bIIoS98=; b=sDuD4UFI9PJQBQG0e7OWT5YAZEzJScmSz6UYFDzU4U4NBMTlPl+NoXiw7DsWClHZIF YSMrMqZpWaSVfnxlq/9/P68ZTljnVfJ8U/KakRM+xr0BNVkRvLJOSW98B40ztPch2f5V fAwIB6AgpH6bAit7BlJkL2Kqou5Yd6Sgbaie4= 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=Ax+AXAzOmO1VUcawCU8DWfVJAJ03wWj02dl5/YQkK46poRwpJiUpWRK/XHF5dA9eHJ sw/rlBMTNqwyweNnYJFqMzVsx0NFz2pzMKvJqgRg11y2nbB6zKfejawFhdqT9uDExBqC HdLu4GslYZplXFflFY+QbLmpvIwUB3aMv2Llw= Received: by 10.114.107.6 with SMTP id f6mr3989668wac.10.1277913854760; Wed, 30 Jun 2010 09:04:14 -0700 (PDT) Received: from windows8d787f9 ([117.89.17.31]) by mx.google.com with ESMTPS id r11sm65461489wah.15.2010.06.30.09.04.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 09:04:13 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'Romascanu, Dan \(Dan\)'" References: In-Reply-To: Date: Wed, 30 Jun 2010 19:03:59 +0300 Message-ID: <4c2b6afd.0bf4720a.7381.6c0d@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: AcsYaFAeb0fUEch6QF2JOfjhgKn4GwAAy98Q Content-Language: en-us Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 16:04:07 -0000 Mary, When I read the charter it is not clear why from the first paragraph you deduct the second paragraph. If the first paragraph will say " The goal of this working group is to enable inter-domain communications over the Internet, using protocols such as SIP, while still allowing people to use the called person assigned circuit switch phone number for identifying the person with whom they wish to communicate. " It may look clearer. Still this is based on the assumption that using other ways to assign and authenticate SIP phone numbers using central databases is not catching up because the carriers object to implement it and not due to any other reason like preferences of enterprises IT to use PSTN for calls because of better quality of service and manageability. Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Wednesday, June 30, 2010 6:24 PM > To: Romascanu, Dan (Dan) > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > Hi Dan, > > The term peer to peer is intended to exclude mechanisms that would use > a central repository for the information: This was discussed in an > earlier thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > In one sense it is a solution, however, in another sense it is reusing > SIP related functionality defined in RAI and thus is in a similar vein > as specifying the use of SIP in a charter. > > Thanks, > Mary. > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > wrote: > >> The VIPR WG will address this problem by developing a peer to > >> peer based approach to finding domains that claim to be > >> responsible for a given phone number and validation protocols > >> to ensure a reasonable likelihood that a given domain > >> actually is responsible for the phone number. > > > > Hi, > > > > Clarification question. What exactly means 'peer to peer based > approach' > > and what kind of approaches are excluded by having this in the > charter. > > Does 'approach' mean solution? If so why does a specific type of > > solution need to be agreed in the charter, while all we have at hand > at > > this point are individual contribution I-Ds that describe the > 'problem > > statement and some possible starting points for solutions'? > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 8:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Wed Jun 30 09:21:14 2010 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 B666A28C0D0; Wed, 30 Jun 2010 09:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 BUWhQF02jeyy; Wed, 30 Jun 2010 09:21:12 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E23E428B56A; Wed, 30 Jun 2010 09:21:11 -0700 (PDT) Received: by iwn40 with SMTP id 40so1064328iwn.31 for ; Wed, 30 Jun 2010 09:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Uq/AINrPGcCuNZ5pxBOIcmyL4EbWcMX2L+1ORRfR2jE=; b=Zz9zyVIAAkPy6iEsDy8P9p9aeS4QhlwGcCbOuCAtI4riNeyCytgiqZTAxW3FcIICKb KtC9ZlqqOAQfUVac0HN7pGzo7xoh2IBpwgh5O2qD+ui84gs7+giEsWYaUZnmuIxFvacQ SBvfnB2OiUY4xqXqym50ZD3EK6tkkE9hf3RvA= 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:content-transfer-encoding; b=npehEpwZGAjcXayUJ3WSa/XxA6RXyHTrZ575DSP9B7ItIdMpl53G96MLolj2Tp7Yr9 J6Vlz3tsztTrkfMlPPtHQw1hD6X38iDUQjbMgY3D+1rWWi71OgZ9xUvUnjWOQ+GnTUQU fIvsP55ZCh2goo0wYiY3lVMbpPRFYljGfVVNs= MIME-Version: 1.0 Received: by 10.231.120.159 with SMTP id d31mr9120949ibr.89.1277914882842; Wed, 30 Jun 2010 09:21:22 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Wed, 30 Jun 2010 09:21:22 -0700 (PDT) In-Reply-To: <4c2b6afd.0bf4720a.7381.6c0d@mx.google.com> References: <4c2b6afd.0bf4720a.7381.6c0d@mx.google.com> Date: Wed, 30 Jun 2010 11:21:22 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 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, 30 Jun 2010 16:21:15 -0000 Hi Roni, Comments inline below and some snipping of the thread. Thanks, Mary. On Wed, Jun 30, 2010 at 11:03 AM, Roni Even wrote: > Mary, > When I read the charter it is not clear why from the first paragraph you > deduct the second paragraph. > If the first paragraph will say > " The goal of this working group is to enable inter-domain communications > over the Internet, using protocols such as SIP, while still allowing peop= le > to use the called person assigned circuit switch phone number for > identifying the person with whom they wish to communicate. " > It may look clearer. [MB] We could change "phone number" to "called person assigned circuit swit= ch phone number for identifying the person", but I think that "phone number" is well understood to be exactly what you want to describe it as. [/MB] > > Still this is based on the assumption that using other ways to assign and > authenticate SIP phone numbers using central databases is not catching up > because the carriers object to implement it and not due to any other reas= on > like preferences of enterprises IT to use PSTN for calls because of bette= r > quality of service and manageability. [MB] I'm not certain (personally) that the latter preferences you note are as prevalent as you might suggest. I would still contend that the larger issue is the former. However, if other folks share this concern, we can certainly add that as well - it reflects equally as being a non-technical reason for widespread implementation [/MB] > > Roni Even > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mary Barnes >> Sent: Wednesday, June 30, 2010 6:24 PM >> To: Romascanu, Dan (Dan) >> Cc: DISPATCH; IETF-Discussion list >> Subject: Re: [dispatch] VIPR - proposed charter version 3 >> >> Hi Dan, >> >> The term peer to peer is intended to exclude mechanisms that would use >> a central repository for the information: =A0This was discussed in an >> earlier thread: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html >> >> In one sense it is a solution, however, in another sense it is reusing >> SIP related functionality defined in RAI and thus is in a similar vein >> as specifying the use of SIP in a charter. >> >> Thanks, >> Mary. >> >> On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) >> wrote: >> >> The VIPR WG will address this problem by developing a peer to >> >> peer based approach to finding domains that claim to be >> >> responsible for a given phone number and validation protocols >> >> to ensure a reasonable likelihood that a given domain >> >> actually is responsible for the phone number. >> > >> > Hi, >> > >> > Clarification question. What exactly means 'peer to peer based >> approach' >> > and what kind of approaches are excluded by having this in the >> charter. >> > Does 'approach' mean solution? If so why does a specific type of >> > solution need to be agreed in the charter, while all we have at hand >> at >> > this point are individual contribution I-Ds that describe the >> 'problem >> > statement and some possible starting points for solutions'? >> > >> > Thanks and Regards, >> > >> > Dan >> > >> > >> >> -----Original Message----- >> >> From: dispatch-bounces@ietf.org >> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes >> >> Sent: Monday, June 28, 2010 8:38 PM >> >> To: DISPATCH >> >> Subject: [dispatch] VIPR - proposed charter version 3 >> >> >> > >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From mary.ietf.barnes@gmail.com Wed Jun 30 09:24:08 2010 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 A0A7428B56A for ; Wed, 30 Jun 2010 09:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSybwXD0F0a6 for ; Wed, 30 Jun 2010 09:23:59 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 038B83A6A1A for ; Wed, 30 Jun 2010 09:23:55 -0700 (PDT) Received: by gwb10 with SMTP id 10so571287gwb.31 for ; Wed, 30 Jun 2010 09:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=LgbbOIysxBVIeG2OSwyQORrt5sG04/3Q6XW9EWcpIhY=; b=iY7TfZeD5sYCjIxmLOD1V/HUEQOigQR5XTY2FTKUyYDY4XBYxEiUr3+MR33BCIUxtn 2GYzh8Xg9mEdJl24Zzd5kQZ1kBYY5KCoOy6XfEhrjaL5zyCbGdDee46lYneSMQdVVXfr m9WwiQ47qLHf5QLN9HRrk9MAoNFqGl5zMh5vY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=i+QaxrqTgR4wtQLurPfavyaKY183HEivIkhIH0JYx5nc1rFdim85jPgZ4m0kHannVe SL9yn1lOr8w9FikaLd6Lfq1j9QfcFGlGGQQk6s0/raZqqI+b0IIJCJIcsDcp3uMdoz6o nMufjXxsFA8GNq9d7YoTckRUWBXDm9jgWTpRs= MIME-Version: 1.0 Received: by 10.102.14.25 with SMTP id 25mr3303075mun.30.1277915041267; Wed, 30 Jun 2010 09:24:01 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Wed, 30 Jun 2010 09:23:59 -0700 (PDT) Date: Wed, 30 Jun 2010 11:23:59 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] VIPR - proposed charter version 4 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, 30 Jun 2010 16:24:08 -0000 Hi all, Below, please find version 4 of the VIPR proposed charter. It's been updated to reflect ML feedback over the past 24 hours. The primary changes are adding some background as to why other solutions are not sufficient and thus a p2p approach is recommended. Also, the deliverables are now described textually rather than listing the current set of individual drafts related to this problem. Regards, Mary (DISPATCH WG co-chair) ============================================ VIPR Charter Proposal (Version 4) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users, thus DNS lookups are not sufficient. Other approaches such as public ENUM are not sufficient due to lack of widespread deployment for non-technical reasons - i.e., the involvement of government and service provider administrative entities needing to approve and populate the registries. Private federations have been established to workaround the issue, however, that solution is not scalable. The goal of this working group is to enable inter-domain communications over the the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications. Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. The validation mechanism requires a domain to gather and maintain information related to PSTN calls. This information is used by call agents such as phones, SBCs and IP PBXs to route calls. The WG will define a client-server protocol between these call agents and the entity within a domain that maintains the information. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP messages are coming from a validated phone number. A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call. The working group will define new SIP headers and option tags, as necessary, to enable this. The essential characteristic of VIPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The solution set defined by this WG will be incrementally deployable using only existing interfaces to the PSTN. No changes will be required to existing PSTN capabilities, no new database access is needed nor is any new support from PSTN service providers required. The WG will produce the following deliverables: 1) A document describing the requirements, problem statement and architectural approach to support SIP inter-domain communications. 2) A document describing the use of the p2psip protocol (RELOAD) as applied to this problem space. 3) A document defining a scheme for validating the phone numbers using publicly available open interfaces to the PSTN. 4) A document defining client-server protocol between call agents and the entity within a domain that gathers and maintains information related to PSTN calls. 5) A document describing a mechanism to mitigate SPAM issues. The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WGs such as sipcore and p2psip. From James.Rafferty@dialogic.com Wed Jun 30 10:56:06 2010 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 565CD3A6A1D; Wed, 30 Jun 2010 10:56:06 -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 yYq5KhGZZWU7; Wed, 30 Jun 2010 10:56:04 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [65.220.90.252]) by core3.amsl.com (Postfix) with ESMTP id 4D11A3A68CD; Wed, 30 Jun 2010 10:56:04 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::bd56:b76c:8d2c:437b]) by pysxht01.dialogic.com ([::1]) with mapi; Wed, 30 Jun 2010 13:56:15 -0400 From: James Rafferty To: Gonzalo Camarillo , Paul Kyzivat Date: Wed, 30 Jun 2010 13:56:10 -0400 Thread-Topic: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcsYILHWFuePWKo0TkaC0Il2ioxBuwAWr40w Message-ID: <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> In-Reply-To: <4C2AE94C.4020707@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Elithy , "dispatch@ietf.org" , "DRAGE, Keith \(Keith\)" , Mohamed, "ietf@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 30 Jun 2010 17:56:06 -0000 Hi,=20 My company has had the experience of deploying the pre-standard version of = this PSTN to SIP UUI mechanism during the past 2 years. =20 As noted in the draft charter, UUI information is widely used on the PSTN f= or applications such as offering input data into call centers and then pres= erving that data as calls get transferred. =20 Since many contact centers are now built using SIP, but still have PSTN sub= scribers (via SS7 ISUP or ISDN PRI), there is a need to be able to interwor= k the user to user information from the PSTN side into SIP. In our experie= nce, the "Johnston uui draft" has accomplished this and we have several cus= tomers that find this interworking to be valuable. We also noted improveme= nts from early drafts into the later ones in areas such as making better us= e of the ITU-T protocol discriminator, thus enabling better interoperabilit= y from the PSTN side into SIP. =20 The major deficiency of the current draft is its non-standard status. Funct= ionally, we and our customers find this mechanism to be very useful and I'd= very much like the IETF to charter the a UUI work group to standardize suc= h a mechanism. =20 James =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Gonzalo Camarillo Sent: Wednesday, June 30, 2010 2:51 AM To: Paul Kyzivat Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Hi, please keep both the IETF and the DISPATCH mailing lists in the recipients list in this discussion. Cheers, Gonzalo On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >=20 >=20 > DRAGE, Keith (Keith) wrote: >> The UUI information is NOT ISUP. It is a transparent envelope to the ent= ire ISDN, so it is not part of an ISDN protocol and therefore not part of a= n ISUP protocol. When carried by ISUP the envelope is bundled up in another= envelope with other information that ISUP carries transparently. >> >> So I believe, and have said repeatedly in the past, that references to S= IP-T are irrelevant in this case. >> >> The problem we do have though is that are legacy usages of this informat= ion. In particular applications in PBXs carry it between themselves in ISDN= call establishment. The information itself is not standardised. If you wan= t to migrate a PBX from DSS1 to SIP, then you have to take this information= into account. The desire is not for a WG group to standardise this existin= g usage (which in my view would be a complete non-starter), but to allow th= e transfer of the existing information when migrated to a SIP environment. = The information transferred does not form part of SIP, and should not be st= andardised as part of SIP. >=20 > How many different mechanisms do we have to construct for the purpose of > tunneling stuff over SIP? >=20 > Its especially bad if the stuff is neither standardized nor negotiated. > It then just provides more opportunity for non-interoperability. >=20 > It had been my impression that this content was standardized by ITU. > If nobody can bother to standardize it, then it hardly seems worth > working on. >=20 > Thanks, > Paul >=20 >> regards >> >> Keith >> >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>> bruno.chatras@orange-ftgroup.com >>> Sent: Tuesday, June 29, 2010 1:00 PM >>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>> for SIP (cuss) >>> >>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>> does state that SIP-T does not come into play when there is >>> no PSTN involved. >>> >>> At the end of clause 2 we can read the following: "4. IP >>> origination - IP termination: This is a case for pure SIP. >>> SIP-T (either encapsulation or translation of ISUP) does not >>> come into play as there is no PSTN interworking." >>> >>> Besides, SIP-T would require encapsulating a full ISUP >>> message (e.g. IAM) while we are interested in just one >>> parameter of the message in the context of CUSS. This would I >>> believe be a more severe drawback if SIP-T were used for this purpose. >>> >>> Bruno >>> >>> >>>> -----Message d'origine----- >>>> De : dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>> Envoy=E9 : mardi 29 juin 2010 13:03 =C0 : DISPATCH Objet : >>> [dispatch] Fwd: >>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>> >>>> Hi, >>>> >>>> FYI: note the discussion below on the IETF general list. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> -------- Original Message -------- >>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>> From: Cullen Jennings >>>> To: iesg@ietf.org >>>> CC: IETF Discussion Mailing List >>>> >>>> >>>> As far as I can tell, the WG says they wants to transfer some >>>> information to achieve cross vendor interoperability. >>>> However, what I believe the charter is actually going to do >>> is exactly >>>> the opposite of that. When you get your head around what >>> this charter >>>> is proposing, it is going to form a more or less opaque >>> container for >>>> transporting proprietary information in a SIP header. It's hard to >>>> imagine how this will help interoperability. >>>> >>>> If we wanted to have interoperability, the charter would say what >>>> information needs to be transferred and have the WG define a way to >>>> get it between systems in an operable way. >>>> What the charter for this WG actually says they are going to do is >>>> make a special container for transfer proprietary information. >>>> There's not even willing to say what that proprietary >>> information is >>>> used for other than things ISDN UUI which is a non >>> interoperable and >>>> fairly proprietary field in ISDN. >>>> Furthermore they have asserted that existing containers >>> such as SIP-T >>>> or SIP bodies can't be used for reasons that are hard to >>> describe. (I >>>> reject the idea that because the call might not involved >>> the PSTN, it >>>> can't use SIP-T). >>>> >>>> I think the folks that want to do this should get a much clear >>>> explanation of how this results in interoperability and why exist >>>> approach such as SIP-T will not work before this is chartered. >>>> >>>> I do think there is a need to standardize some important >>> call control >>>> information used in call centers and related places. >>>> However, the "we need a standard container to exchange secret >>>> information WG" is a bad idea and violates the sprit of the >>> SIP change >>>> process not to mention the mission of the IETF. >>>> >>>> In summary, I'm in favor of figuring out what the problems >>> are people >>>> hope to solve with this WG and figuring out a way to write >>>> interoperable standards to achieve that. However, I think >>> this charter >>>> should be rejected by the IESG and sent back to the drawing >>> board. The >>>> RAI area has things of higher priority items to work on than a SIP >>>> header for transfer proprietary data. >>>> >>>> >>>> >>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>> >>>>> A new IETF working group has been proposed in the Real-time >>>>> Applications and Infrastructure Area. The IESG has not >>>> made any determination as yet. >>>>> The following draft charter was submitted, and is provided for >>>>> informational purposes only. Please send your comments to >>> the IESG >>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>> >>>>> Call Control UUI for SIP (cuss) >>>>> -------------------------------------------------- >>>>> Current Status: Proposed Working Group >>>>> >>>>> Last modified: 2010-06-21 >>>>> >>>>> Chair(s): >>>>> TBD >>>>> >>>>> Real-time Applications and Infrastructure Area Director(s): >>>>> Gonzalo Camarillo >>> Robert Sparks >>>>> >>>>> >>>>> Real-time Applications and Infrastructure Area Advisor: >>>>> Gonzalo Camarillo >>>>> >>>>> Mailing Lists: TBD >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>> define a Session Initiation Protocol (SIP) mechanism for >>>> transporting >>>>> call-control related user-to-user information (UUI) between User >>>>> Agents. >>>>> >>>>> The mechanism developed in this working group is >>> applicable in the >>>>> following situations: >>>>> >>>>> 1. The information is generated and consumed by an >>> application using >>>>> SIP during session setup but the application is not necessarily >>>>> even SIP aware. >>>>> 2. The behavior of SIP entities that support it is not >>> significantly >>>>> changed (as discussed in Section 4 of RFC 5727). >>>>> 3. Generally only the User Agent Client (UAC) and User >>> Agent Server >>>>> (UAS) are interested in the information. >>>>> 4. The information is expected to survive retargeting, >>> redirection, >>>>> and transfers. >>>>> 5. SIP elements may need to apply policy about passing >>> and screening >>>>> the information. >>>>> 6. Multi-vendor interoperability is important. >>>>> >>>>> This mechanism is not applicable in the following situations: >>>>> >>>>> 1. The behavior of SIP entities that support it is significantly >>>>> changed (as discussed in Section 4 of RFC 5727). >>>>> 2. The information is generated and consumed at the SIP >>> layer by SIP >>>>> elements. >>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>> consuming (beyond applying policy) the information. >>>>> 4. There are specific privacy issues involved with the information >>>>> being transported (e.g., geolocation or emergency-related >>>>> information). >>>>> >>>>> User data of the mechanism will be clearly marked with the >>>>> application, encoding, semantics, and content type, >>>> allowing policy to >>>>> be applied by UAs. The working group will define the >>>> information that >>>>> each application must specify to utilize the mechanism. >>>> This type of >>>>> application-specific information will be specified in >>>> standards-track >>>>> documents. >>>>> >>>>> One important application of this mechanism is interworking >>>> with the >>>>> ISDN User to User Information Service. This application >>> defined by >>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>> supporting such >>>>> applications as contact centers, call centers, and automatic call >>>>> distributors (ACDs). A major barrier to the movement of these >>>>> applications to SIP is the lack of a standard mechanism to >>>> transport >>>>> this information in SIP. For interworking with ISDN, minimal >>>>> information about the content of the UUI is available to >>>> the PSTN-SIP >>>>> gateways. In this case only, the content will just >>>> indicate ISDN UUI >>>>> Service 1 interworking rather than the actual content. >>>>> >>>>> Call control UUI is user information conveyed between user agents >>>>> during call control operations. As a result, the >>>> information must be >>>>> conveyed with the INVITE transaction, and must survive proxy >>>>> retargeting, redirection, and transfers. The mechanism >>>> must utilize a >>>>> minimum of SIP extensions since it will need to be >>>> supported by many >>>>> simple SIP user agents such as PSTN gateways. The mechanism must >>>>> interwork with the existing ISDN service but should also be >>>> extensible >>>>> for use by other applications and non-ISDN protocols. >>>>> >>>>> Even though interworking with the PSTN is an important >>> requirement, >>>>> call control UUI can be exchanged between native SIP >>>> clients that do >>>>> not have any ISUP support. Therefore, existing SIP-T >>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>> requirements to transport this type of information. >>>>> >>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>> considered by the working group since the UUI contents carry >>>>> information that must be conveyed during session setup at >>> the user >>>>> agent - the information must be conveyed with the INVITE >>>> transaction. >>>>> The information 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. >>>>> >>>>> The group will produce: >>>>> >>>>> - A problem statement and requirements document for >>>> implementing a SIP >>>>> call control UUI mechanism >>>>> >>>>> - A specification of the SIP extension to best meet those >>>> requirements. >>>>> Goals and Milestones >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> Sep 10 - Problem statement and requirements document to IESG >>>>> (Informational) >>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>> >>>> Cullen Jennings >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 pkyzivat@cisco.com Wed Jun 30 11:19:49 2010 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 B67D63A6AD5; Wed, 30 Jun 2010 11:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa5+FjRan66A; Wed, 30 Jun 2010 11:19:47 -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 4A8873A67F5; Wed, 30 Jun 2010 11:19:47 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADcnK0yrRN+K/2dsb2JhbACfU3GmPpo1gnEIgiwEiCM X-IronPort-AV: E=Sophos;i="4.53,514,1272844800"; d="scan'208";a="552572436" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2010 18:19:57 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o5UIJu9O007800; Wed, 30 Jun 2010 18:19:57 GMT Message-ID: <4C2B8ACE.3050301@cisco.com> Date: Wed, 30 Jun 2010 14:19:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: James Rafferty References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> In-Reply-To: <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "DRAGE, Keith \(Keith\)" , Mohamed Elithy , "dispatch@ietf.org" , "ietf@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 30 Jun 2010 18:19:49 -0000 James, Can you shed some light on *how* this is used, given the lack of any standards on the content/formatting of this information? Do you use content=isdn-uui and some particular Q.931 protocol discriminator for which there are formatting standards? Or is this only used between a caller and a callee that have somehow obtained contextual information that they both support this feature *and* a particular encoding? Thanks, Paul James Rafferty wrote: > Hi, > > My company has had the experience of deploying the pre-standard version of this PSTN to SIP UUI mechanism during the past 2 years. > > As noted in the draft charter, UUI information is widely used on the PSTN for applications such as offering input data into call centers and then preserving that data as calls get transferred. > > Since many contact centers are now built using SIP, but still have PSTN subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to interwork the user to user information from the PSTN side into SIP. In our experience, the "Johnston uui draft" has accomplished this and we have several customers that find this interworking to be valuable. We also noted improvements from early drafts into the later ones in areas such as making better use of the ITU-T protocol discriminator, thus enabling better interoperability from the PSTN side into SIP. > > The major deficiency of the current draft is its non-standard status. Functionally, we and our customers find this mechanism to be very useful and I'd very much like the IETF to charter the a UUI work group to standardize such a mechanism. > > James > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Wednesday, June 30, 2010 2:51 AM > To: Paul Kyzivat > Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org > Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) > > Hi, > > please keep both the IETF and the DISPATCH mailing lists in the > recipients list in this discussion. > > Cheers, > > Gonzalo > > > On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >> >> DRAGE, Keith (Keith) wrote: >>> The UUI information is NOT ISUP. It is a transparent envelope to the entire ISDN, so it is not part of an ISDN protocol and therefore not part of an ISUP protocol. When carried by ISUP the envelope is bundled up in another envelope with other information that ISUP carries transparently. >>> >>> So I believe, and have said repeatedly in the past, that references to SIP-T are irrelevant in this case. >>> >>> The problem we do have though is that are legacy usages of this information. In particular applications in PBXs carry it between themselves in ISDN call establishment. The information itself is not standardised. If you want to migrate a PBX from DSS1 to SIP, then you have to take this information into account. The desire is not for a WG group to standardise this existing usage (which in my view would be a complete non-starter), but to allow the transfer of the existing information when migrated to a SIP environment. The information transferred does not form part of SIP, and should not be standardised as part of SIP. >> How many different mechanisms do we have to construct for the purpose of >> tunneling stuff over SIP? >> >> Its especially bad if the stuff is neither standardized nor negotiated. >> It then just provides more opportunity for non-interoperability. >> >> It had been my impression that this content was standardized by ITU. >> If nobody can bother to standardize it, then it hardly seems worth >> working on. >> >> Thanks, >> Paul >> >>> regards >>> >>> Keith >>> >>> >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>>> bruno.chatras@orange-ftgroup.com >>>> Sent: Tuesday, June 29, 2010 1:00 PM >>>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>>> for SIP (cuss) >>>> >>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>>> does state that SIP-T does not come into play when there is >>>> no PSTN involved. >>>> >>>> At the end of clause 2 we can read the following: "4. IP >>>> origination - IP termination: This is a case for pure SIP. >>>> SIP-T (either encapsulation or translation of ISUP) does not >>>> come into play as there is no PSTN interworking." >>>> >>>> Besides, SIP-T would require encapsulating a full ISUP >>>> message (e.g. IAM) while we are interested in just one >>>> parameter of the message in the context of CUSS. This would I >>>> believe be a more severe drawback if SIP-T were used for this purpose. >>>> >>>> Bruno >>>> >>>> >>>>> -----Message d'origine----- >>>>> De : dispatch-bounces@ietf.org >>>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>>> Envoyé : mardi 29 juin 2010 13:03 À : DISPATCH Objet : >>>> [dispatch] Fwd: >>>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>>> >>>>> Hi, >>>>> >>>>> FYI: note the discussion below on the IETF general list. >>>>> >>>>> Cheers, >>>>> >>>>> Gonzalo >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>>> From: Cullen Jennings >>>>> To: iesg@ietf.org >>>>> CC: IETF Discussion Mailing List >>>>> >>>>> >>>>> As far as I can tell, the WG says they wants to transfer some >>>>> information to achieve cross vendor interoperability. >>>>> However, what I believe the charter is actually going to do >>>> is exactly >>>>> the opposite of that. When you get your head around what >>>> this charter >>>>> is proposing, it is going to form a more or less opaque >>>> container for >>>>> transporting proprietary information in a SIP header. It's hard to >>>>> imagine how this will help interoperability. >>>>> >>>>> If we wanted to have interoperability, the charter would say what >>>>> information needs to be transferred and have the WG define a way to >>>>> get it between systems in an operable way. >>>>> What the charter for this WG actually says they are going to do is >>>>> make a special container for transfer proprietary information. >>>>> There's not even willing to say what that proprietary >>>> information is >>>>> used for other than things ISDN UUI which is a non >>>> interoperable and >>>>> fairly proprietary field in ISDN. >>>>> Furthermore they have asserted that existing containers >>>> such as SIP-T >>>>> or SIP bodies can't be used for reasons that are hard to >>>> describe. (I >>>>> reject the idea that because the call might not involved >>>> the PSTN, it >>>>> can't use SIP-T). >>>>> >>>>> I think the folks that want to do this should get a much clear >>>>> explanation of how this results in interoperability and why exist >>>>> approach such as SIP-T will not work before this is chartered. >>>>> >>>>> I do think there is a need to standardize some important >>>> call control >>>>> information used in call centers and related places. >>>>> However, the "we need a standard container to exchange secret >>>>> information WG" is a bad idea and violates the sprit of the >>>> SIP change >>>>> process not to mention the mission of the IETF. >>>>> >>>>> In summary, I'm in favor of figuring out what the problems >>>> are people >>>>> hope to solve with this WG and figuring out a way to write >>>>> interoperable standards to achieve that. However, I think >>>> this charter >>>>> should be rejected by the IESG and sent back to the drawing >>>> board. The >>>>> RAI area has things of higher priority items to work on than a SIP >>>>> header for transfer proprietary data. >>>>> >>>>> >>>>> >>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>>> >>>>>> A new IETF working group has been proposed in the Real-time >>>>>> Applications and Infrastructure Area. The IESG has not >>>>> made any determination as yet. >>>>>> The following draft charter was submitted, and is provided for >>>>>> informational purposes only. Please send your comments to >>>> the IESG >>>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>>> >>>>>> Call Control UUI for SIP (cuss) >>>>>> -------------------------------------------------- >>>>>> Current Status: Proposed Working Group >>>>>> >>>>>> Last modified: 2010-06-21 >>>>>> >>>>>> Chair(s): >>>>>> TBD >>>>>> >>>>>> Real-time Applications and Infrastructure Area Director(s): >>>>>> Gonzalo Camarillo >>>> Robert Sparks >>>>>> >>>>>> >>>>>> Real-time Applications and Infrastructure Area Advisor: >>>>>> Gonzalo Camarillo >>>>>> >>>>>> Mailing Lists: TBD >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>>> define a Session Initiation Protocol (SIP) mechanism for >>>>> transporting >>>>>> call-control related user-to-user information (UUI) between User >>>>>> Agents. >>>>>> >>>>>> The mechanism developed in this working group is >>>> applicable in the >>>>>> following situations: >>>>>> >>>>>> 1. The information is generated and consumed by an >>>> application using >>>>>> SIP during session setup but the application is not necessarily >>>>>> even SIP aware. >>>>>> 2. The behavior of SIP entities that support it is not >>>> significantly >>>>>> changed (as discussed in Section 4 of RFC 5727). >>>>>> 3. Generally only the User Agent Client (UAC) and User >>>> Agent Server >>>>>> (UAS) are interested in the information. >>>>>> 4. The information is expected to survive retargeting, >>>> redirection, >>>>>> and transfers. >>>>>> 5. SIP elements may need to apply policy about passing >>>> and screening >>>>>> the information. >>>>>> 6. Multi-vendor interoperability is important. >>>>>> >>>>>> This mechanism is not applicable in the following situations: >>>>>> >>>>>> 1. The behavior of SIP entities that support it is significantly >>>>>> changed (as discussed in Section 4 of RFC 5727). >>>>>> 2. The information is generated and consumed at the SIP >>>> layer by SIP >>>>>> elements. >>>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>>> consuming (beyond applying policy) the information. >>>>>> 4. There are specific privacy issues involved with the information >>>>>> being transported (e.g., geolocation or emergency-related >>>>>> information). >>>>>> >>>>>> User data of the mechanism will be clearly marked with the >>>>>> application, encoding, semantics, and content type, >>>>> allowing policy to >>>>>> be applied by UAs. The working group will define the >>>>> information that >>>>>> each application must specify to utilize the mechanism. >>>>> This type of >>>>>> application-specific information will be specified in >>>>> standards-track >>>>>> documents. >>>>>> >>>>>> One important application of this mechanism is interworking >>>>> with the >>>>>> ISDN User to User Information Service. This application >>>> defined by >>>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>>> supporting such >>>>>> applications as contact centers, call centers, and automatic call >>>>>> distributors (ACDs). A major barrier to the movement of these >>>>>> applications to SIP is the lack of a standard mechanism to >>>>> transport >>>>>> this information in SIP. For interworking with ISDN, minimal >>>>>> information about the content of the UUI is available to >>>>> the PSTN-SIP >>>>>> gateways. In this case only, the content will just >>>>> indicate ISDN UUI >>>>>> Service 1 interworking rather than the actual content. >>>>>> >>>>>> Call control UUI is user information conveyed between user agents >>>>>> during call control operations. As a result, the >>>>> information must be >>>>>> conveyed with the INVITE transaction, and must survive proxy >>>>>> retargeting, redirection, and transfers. The mechanism >>>>> must utilize a >>>>>> minimum of SIP extensions since it will need to be >>>>> supported by many >>>>>> simple SIP user agents such as PSTN gateways. The mechanism must >>>>>> interwork with the existing ISDN service but should also be >>>>> extensible >>>>>> for use by other applications and non-ISDN protocols. >>>>>> >>>>>> Even though interworking with the PSTN is an important >>>> requirement, >>>>>> call control UUI can be exchanged between native SIP >>>>> clients that do >>>>>> not have any ISUP support. Therefore, existing SIP-T >>>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>>> requirements to transport this type of information. >>>>>> >>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>>> considered by the working group since the UUI contents carry >>>>>> information that must be conveyed during session setup at >>>> the user >>>>>> agent - the information must be conveyed with the INVITE >>>>> transaction. >>>>>> The information 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. >>>>>> >>>>>> The group will produce: >>>>>> >>>>>> - A problem statement and requirements document for >>>>> implementing a SIP >>>>>> call control UUI mechanism >>>>>> >>>>>> - A specification of the SIP extension to best meet those >>>>> requirements. >>>>>> Goals and Milestones >>>>>> ==================== >>>>>> >>>>>> Sep 10 - Problem statement and requirements document to IESG >>>>>> (Informational) >>>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>>> _______________________________________________ >>>>>> IETF-Announce mailing list >>>>>> IETF-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> Cullen Jennings >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 pkyzivat@cisco.com Wed Jun 30 16:20:30 2010 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 064633A659C; Wed, 30 Jun 2010 16:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.96 X-Spam-Level: X-Spam-Status: No, score=-9.96 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUqPEfBcbn6i; Wed, 30 Jun 2010 16:20:27 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EA5E43A6857; Wed, 30 Jun 2010 16:20:25 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP9tK0xAZnwM/2dsb2JhbACfVXGleJpFgnEHAYIsBIgj X-IronPort-AV: E=Sophos;i="4.53,516,1272844800"; d="scan'208";a="127366745" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Jun 2010 23:20:36 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5UNKaYZ016036; Wed, 30 Jun 2010 23:20:36 GMT Message-ID: <4C2BD141.1000903@cisco.com> Date: Wed, 30 Jun 2010 19:20:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mohamed Elithy References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> <617DF0128820F9458AC39149A627EE6C01A66BC431@MBX.dialogic.com> In-Reply-To: <617DF0128820F9458AC39149A627EE6C01A66BC431@MBX.dialogic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "DRAGE, Keith \(Keith\)" , "dispatch@ietf.org" , "ietf@ietf.org" , James Rafferty Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) 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, 30 Jun 2010 23:20:30 -0000 Mohamed Elithy wrote: > Hi! > We are currently adding all 3 parameters (encoding, content, and purpose) in case of an ISDN --> SIP initiated call with their specified default values defined in section 5 of the draft. > > As far as the formatting, as the draft specifies the first byte of the header value is the protocol discriminator. we found that the best way to satisfy multiple customers dealing with different types of encoding is to pass the protocol discriminator along with the raw byte stream from the UUI IE on the ISDN side to the UUI header on the SIP side. This way the SIP AS or any other SIP entity receiving that header can decide how to decode the UUI info based on the value of the protocol discriminator. I got all that. My question was about what specific value(s?) of the protocol discriminator are you using, and how do they correspond to the rest of the value. The same question would apply if sip were not involved at all - if the call were an ISDN call. Is there a broad based convention that most call center sw will use a particular encoding? Or is it well known that certain commercial products use certain encodings? Or is this just a private side arrangement configured between the caller and the callee in a specific deployment? Thanks, Paul > Hope this helps. > > Regards, > -Mohamed > > Mohamed Elithy | Engineering Manager/Architect | Dialogic Inc. | mohamed.elithy@dialogic.com | 508-862-3722 W | 508-364-5526 M > > This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail. > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, June 30, 2010 2:20 PM > To: James Rafferty > Cc: Gonzalo Camarillo; dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org; Mohamed Elithy > Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) > > James, > > Can you shed some light on *how* this is used, given the lack of any > standards on the content/formatting of this information? > > Do you use content=isdn-uui and some particular Q.931 protocol > discriminator for which there are formatting standards? > > Or is this only used between a caller and a callee that have somehow > obtained contextual information that they both support this feature > *and* a particular encoding? > > Thanks, > Paul > > James Rafferty wrote: >> Hi, >> >> My company has had the experience of deploying the pre-standard version of this PSTN to SIP UUI mechanism during the past 2 years. >> >> As noted in the draft charter, UUI information is widely used on the PSTN for applications such as offering input data into call centers and then preserving that data as calls get transferred. >> >> Since many contact centers are now built using SIP, but still have PSTN subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to interwork the user to user information from the PSTN side into SIP. In our experience, the "Johnston uui draft" has accomplished this and we have several customers that find this interworking to be valuable. We also noted improvements from early drafts into the later ones in areas such as making better use of the ITU-T protocol discriminator, thus enabling better interoperability from the PSTN side into SIP. >> >> The major deficiency of the current draft is its non-standard status. Functionally, we and our customers find this mechanism to be very useful and I'd very much like the IETF to charter the a UUI work group to standardize such a mechanism. >> >> James >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: Wednesday, June 30, 2010 2:51 AM >> To: Paul Kyzivat >> Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org >> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) >> >> Hi, >> >> please keep both the IETF and the DISPATCH mailing lists in the >> recipients list in this discussion. >> >> Cheers, >> >> Gonzalo >> >> >> On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >>> DRAGE, Keith (Keith) wrote: >>>> The UUI information is NOT ISUP. It is a transparent envelope to the entire ISDN, so it is not part of an ISDN protocol and therefore not part of an ISUP protocol. When carried by ISUP the envelope is bundled up in another envelope with other information that ISUP carries transparently. >>>> >>>> So I believe, and have said repeatedly in the past, that references to SIP-T are irrelevant in this case. >>>> >>>> The problem we do have though is that are legacy usages of this information. In particular applications in PBXs carry it between themselves in ISDN call establishment. The information itself is not standardised. If you want to migrate a PBX from DSS1 to SIP, then you have to take this information into account. The desire is not for a WG group to standardise this existing usage (which in my view would be a complete non-starter), but to allow the transfer of the existing information when migrated to a SIP environment. The information transferred does not form part of SIP, and should not be standardised as part of SIP. >>> How many different mechanisms do we have to construct for the purpose of >>> tunneling stuff over SIP? >>> >>> Its especially bad if the stuff is neither standardized nor negotiated. >>> It then just provides more opportunity for non-interoperability. >>> >>> It had been my impression that this content was standardized by ITU. >>> If nobody can bother to standardize it, then it hardly seems worth >>> working on. >>> >>> Thanks, >>> Paul >>> >>>> regards >>>> >>>> Keith >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>>>> bruno.chatras@orange-ftgroup.com >>>>> Sent: Tuesday, June 29, 2010 1:00 PM >>>>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>>>> for SIP (cuss) >>>>> >>>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>>>> does state that SIP-T does not come into play when there is >>>>> no PSTN involved. >>>>> >>>>> At the end of clause 2 we can read the following: "4. IP >>>>> origination - IP termination: This is a case for pure SIP. >>>>> SIP-T (either encapsulation or translation of ISUP) does not >>>>> come into play as there is no PSTN interworking." >>>>> >>>>> Besides, SIP-T would require encapsulating a full ISUP >>>>> message (e.g. IAM) while we are interested in just one >>>>> parameter of the message in the context of CUSS. This would I >>>>> believe be a more severe drawback if SIP-T were used for this purpose. >>>>> >>>>> Bruno >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>>>> Envoyé : mardi 29 juin 2010 13:03 À : DISPATCH Objet : >>>>> [dispatch] Fwd: >>>>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>>>> >>>>>> Hi, >>>>>> >>>>>> FYI: note the discussion below on the IETF general list. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>>>> From: Cullen Jennings >>>>>> To: iesg@ietf.org >>>>>> CC: IETF Discussion Mailing List >>>>>> >>>>>> >>>>>> As far as I can tell, the WG says they wants to transfer some >>>>>> information to achieve cross vendor interoperability. >>>>>> However, what I believe the charter is actually going to do >>>>> is exactly >>>>>> the opposite of that. When you get your head around what >>>>> this charter >>>>>> is proposing, it is going to form a more or less opaque >>>>> container for >>>>>> transporting proprietary information in a SIP header. It's hard to >>>>>> imagine how this will help interoperability. >>>>>> >>>>>> If we wanted to have interoperability, the charter would say what >>>>>> information needs to be transferred and have the WG define a way to >>>>>> get it between systems in an operable way. >>>>>> What the charter for this WG actually says they are going to do is >>>>>> make a special container for transfer proprietary information. >>>>>> There's not even willing to say what that proprietary >>>>> information is >>>>>> used for other than things ISDN UUI which is a non >>>>> interoperable and >>>>>> fairly proprietary field in ISDN. >>>>>> Furthermore they have asserted that existing containers >>>>> such as SIP-T >>>>>> or SIP bodies can't be used for reasons that are hard to >>>>> describe. (I >>>>>> reject the idea that because the call might not involved >>>>> the PSTN, it >>>>>> can't use SIP-T). >>>>>> >>>>>> I think the folks that want to do this should get a much clear >>>>>> explanation of how this results in interoperability and why exist >>>>>> approach such as SIP-T will not work before this is chartered. >>>>>> >>>>>> I do think there is a need to standardize some important >>>>> call control >>>>>> information used in call centers and related places. >>>>>> However, the "we need a standard container to exchange secret >>>>>> information WG" is a bad idea and violates the sprit of the >>>>> SIP change >>>>>> process not to mention the mission of the IETF. >>>>>> >>>>>> In summary, I'm in favor of figuring out what the problems >>>>> are people >>>>>> hope to solve with this WG and figuring out a way to write >>>>>> interoperable standards to achieve that. However, I think >>>>> this charter >>>>>> should be rejected by the IESG and sent back to the drawing >>>>> board. The >>>>>> RAI area has things of higher priority items to work on than a SIP >>>>>> header for transfer proprietary data. >>>>>> >>>>>> >>>>>> >>>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>>>> >>>>>>> A new IETF working group has been proposed in the Real-time >>>>>>> Applications and Infrastructure Area. The IESG has not >>>>>> made any determination as yet. >>>>>>> The following draft charter was submitted, and is provided for >>>>>>> informational purposes only. Please send your comments to >>>>> the IESG >>>>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>>>> >>>>>>> Call Control UUI for SIP (cuss) >>>>>>> -------------------------------------------------- >>>>>>> Current Status: Proposed Working Group >>>>>>> >>>>>>> Last modified: 2010-06-21 >>>>>>> >>>>>>> Chair(s): >>>>>>> TBD >>>>>>> >>>>>>> Real-time Applications and Infrastructure Area Director(s): >>>>>>> Gonzalo Camarillo >>>>> Robert Sparks >>>>>>> >>>>>>> >>>>>>> Real-time Applications and Infrastructure Area Advisor: >>>>>>> Gonzalo Camarillo >>>>>>> >>>>>>> Mailing Lists: TBD >>>>>>> >>>>>>> Description of Working Group: >>>>>>> >>>>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>>>> define a Session Initiation Protocol (SIP) mechanism for >>>>>> transporting >>>>>>> call-control related user-to-user information (UUI) between User >>>>>>> Agents. >>>>>>> >>>>>>> The mechanism developed in this working group is >>>>> applicable in the >>>>>>> following situations: >>>>>>> >>>>>>> 1. The information is generated and consumed by an >>>>> application using >>>>>>> SIP during session setup but the application is not necessarily >>>>>>> even SIP aware. >>>>>>> 2. The behavior of SIP entities that support it is not >>>>> significantly >>>>>>> changed (as discussed in Section 4 of RFC 5727). >>>>>>> 3. Generally only the User Agent Client (UAC) and User >>>>> Agent Server >>>>>>> (UAS) are interested in the information. >>>>>>> 4. The information is expected to survive retargeting, >>>>> redirection, >>>>>>> and transfers. >>>>>>> 5. SIP elements may need to apply policy about passing >>>>> and screening >>>>>>> the information. >>>>>>> 6. Multi-vendor interoperability is important. >>>>>>> >>>>>>> This mechanism is not applicable in the following situations: >>>>>>> >>>>>>> 1. The behavior of SIP entities that support it is significantly >>>>>>> changed (as discussed in Section 4 of RFC 5727). >>>>>>> 2. The information is generated and consumed at the SIP >>>>> layer by SIP >>>>>>> elements. >>>>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>>>> consuming (beyond applying policy) the information. >>>>>>> 4. There are specific privacy issues involved with the information >>>>>>> being transported (e.g., geolocation or emergency-related >>>>>>> information). >>>>>>> >>>>>>> User data of the mechanism will be clearly marked with the >>>>>>> application, encoding, semantics, and content type, >>>>>> allowing policy to >>>>>>> be applied by UAs. The working group will define the >>>>>> information that >>>>>>> each application must specify to utilize the mechanism. >>>>>> This type of >>>>>>> application-specific information will be specified in >>>>>> standards-track >>>>>>> documents. >>>>>>> >>>>>>> One important application of this mechanism is interworking >>>>>> with the >>>>>>> ISDN User to User Information Service. This application >>>>> defined by >>>>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>>>> supporting such >>>>>>> applications as contact centers, call centers, and automatic call >>>>>>> distributors (ACDs). A major barrier to the movement of these >>>>>>> applications to SIP is the lack of a standard mechanism to >>>>>> transport >>>>>>> this information in SIP. For interworking with ISDN, minimal >>>>>>> information about the content of the UUI is available to >>>>>> the PSTN-SIP >>>>>>> gateways. In this case only, the content will just >>>>>> indicate ISDN UUI >>>>>>> Service 1 interworking rather than the actual content. >>>>>>> >>>>>>> Call control UUI is user information conveyed between user agents >>>>>>> during call control operations. As a result, the >>>>>> information must be >>>>>>> conveyed with the INVITE transaction, and must survive proxy >>>>>>> retargeting, redirection, and transfers. The mechanism >>>>>> must utilize a >>>>>>> minimum of SIP extensions since it will need to be >>>>>> supported by many >>>>>>> simple SIP user agents such as PSTN gateways. The mechanism must >>>>>>> interwork with the existing ISDN service but should also be >>>>>> extensible >>>>>>> for use by other applications and non-ISDN protocols. >>>>>>> >>>>>>> Even though interworking with the PSTN is an important >>>>> requirement, >>>>>>> call control UUI can be exchanged between native SIP >>>>>> clients that do >>>>>>> not have any ISUP support. Therefore, existing SIP-T >>>>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>>>> requirements to transport this type of information. >>>>>>> >>>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>>>> considered by the working group since the UUI contents carry >>>>>>> information that must be conveyed during session setup at >>>>> the user >>>>>>> agent - the information must be conveyed with the INVITE >>>>>> transaction. >>>>>>> The information 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. >>>>>>> >>>>>>> The group will produce: >>>>>>> >>>>>>> - A problem statement and requirements document for >>>>>> implementing a SIP >>>>>>> call control UUI mechanism >>>>>>> >>>>>>> - A specification of the SIP extension to best meet those >>>>>> requirements. >>>>>>> Goals and Milestones >>>>>>> ==================== >>>>>>> >>>>>>> Sep 10 - Problem statement and requirements document to IESG >>>>>>> (Informational) >>>>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>>>> _______________________________________________ >>>>>>> IETF-Announce mailing list >>>>>>> IETF-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>> Cullen Jennings >>>>>> For corporate legal information go to: >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > >