From marcelo-digital_@datafull.com Tue Mar 4 04:41:33 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B39F3A6A3C for ; Tue, 4 Mar 2008 04:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.296 X-Spam-Level: **** X-Spam-Status: No, score=4.296 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, DNS_FROM_AHBL_RHSBL=0.692, DNS_FROM_RFC_BOGUSMX=1.482, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRFvVD4YVxH5 for ; Tue, 4 Mar 2008 04:41:32 -0800 (PST) Received: from avas-mr03.fibertel.com.ar (avas-mr03.fibertel.com.ar [24.232.0.216]) by core3.amsl.com (Postfix) with ESMTP id 6C90C3A6C05 for ; Tue, 4 Mar 2008 04:41:22 -0800 (PST) Received: from 201-213-141-172.net.prima.net.ar ([201.213.141.172]:2737 "EHLO desktop" smtp-auth: "zoolander" rhost-flags-OK-OK-OK-FAIL) by avas-mr03.fibertel.com.ar with ESMTPA id S589808AbYCDMlB convert rfc822-to-8bit; Tue, 4 Mar 2008 10:41:01 -0200 Message-ID: <412-22008324940520@desktop> To: "TIERRA DIGITAL" From: "Tierra Digital" Subject: COMPUTADORAS COMPLETAS MARZO 2008 Date: Tue, 4 Mar 2008 10:40:52 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-Fib-Al-Info: Al X-Fib-Al-MRId: 12d2b2c3a500dffbca9682b248c0fbb7 X-Fib-Al: noav X-Fib-Al-SA: analyzed X-Fib-Al-From: marcelo-digital_@datafull.com TIERRA DIGITAL TE: 011-15-6971-7166 EMAIL: marcelo-digital@datafull.com EMAIL: marcelodigital@mail.ru MSN: marcelo-digital@datafull.com IDEAL PARA EMPRESAS, precios Finales con Factura A o B, entrega en local de Computacion en la zona de Caballito, Capital Federal. Argentina Las computadoras no incluyen MONITOR AGREGAMOS TARJETA SHOPPING Aceptamos pago con Tarjetas de Credito VISA, Mastercard, Tarjeta Shopping, American Express, Cabal y Carta Franca Creditos en el acto con DNI, recibo de Sueldo y un Servicio a nombre del titular o pariente Monitor Samsung CRT 794V Black $399 Monitor Samsung 17" LCD 732NW $725 Portaretrato Digital 7" TITAN $329 Modelo ATHLON FIRE Procesador AMD ATHLON 64 DUAL CORE 4200+ Socket AM2 BOX Motherboard MSI K9N6GM-V / ASUS M2N-MX, chipset nVidia nForce 430 Memoria 1GB DDR2 667 Placa de Video VGA nVidia GeForce 6100GS 256MB Disco Rigido Western Digital 80GB SATA2 Optico ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red 10/100 Sonido 8 canales Puertos 2 USB frontales + 4USB traseros KIT ATX SENTEY KIT RJA-253 NEGRO / Teclado Multimedia / Mouse Optico Garantia 12 meses Precio Efectivo $ 1079 CUOTAS 12 cuotas de $114,25 Con sistema operativo Windows XP instalado y funcionando FULL, todos los programas y utilidades Modelo DUAL CORE FULL Procesador CPU INTEL E2160 DUAL CORE 1.6 1MB Socket 775 BOX Motherboard ASUS P5S-MX BOX Memoria 1GB DDR2 667 Placa de Video VGA PCI-Express 256MB REALES NX8400GS MSI Disco Rigido Western Digital 250GB SATA2 Optico ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red 10/100 Sonido 8 canales Puertos 2 USB frontales + 4USB traseros GABINETE SENTEY R274 con DISPLAY Garantia 12 meses Precio $ 1.489 CUOTAS 12 cuotas de $157,66 Con sistema operativo Windows XP instalado y funcionando FULL, todos los programas y utilidades Modelo CORE 2 DUO Procesador INTEL E4500 CORE2DUO 2.0 2MB Socket 775 BOX Motherboard ASUS P5LD2-X BOX Memoria 1GB DDR2 667 Placa de Video VGA PCI-Express 256MB REALES NX8400GS MSI Disco Rigido Western Digital 250GB SATA2 Optico ReGrabadora de DVD DVDRW PHILIPS 20X Placa Red 10/100 Sonido 8 canales Puertos 2 USB frontales + 4USB traseros GABINETE SATELLITE 511 BLADE con DISPLAY y 3 COOLERS COLOR Garantia 12 meses Precio $ 1.819 CUOTAS 12 cuotas de $192,60 Con sistema operativo Windows XP instalado y funcionando FULL, todos los programas y utilidades TIERRA DIGITAL TE: 011-15-6971-7166 EMAIL: marcelo-digital@datafull.com EMAIL: marcelodigital@mail.ru MSN: marcelo-digital@datafull.com From iptel-bounces@ietf.org Sat Mar 8 06:15:58 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C22A28E2F8; Sat, 8 Mar 2008 06:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.208 X-Spam-Level: X-Spam-Status: No, score=-100.208 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_93=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTTT3BQ--9XN; Sat, 8 Mar 2008 06:15:53 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD33E28C1FD; Sat, 8 Mar 2008 05:35:09 -0800 (PST) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C83428CCDF; Sat, 8 Mar 2008 05:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-3QYj4yDSfj; Sat, 8 Mar 2008 05:35:07 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id B501828E5FB; Fri, 7 Mar 2008 16:00:23 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id D886D1188DB; Fri, 7 Mar 2008 16:00:12 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080308000012.D886D1188DB@bosco.isi.edu> Date: Fri, 7 Mar 2008 16:00:12 -0800 (PST) Cc: iptel@ietf.org, rfc-editor@rfc-editor.org Subject: [Iptel] RFC 5140 on A Telephony Gateway REgistration Protocol (TGREP) X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5140 Title: A Telephony Gateway REgistration Protocol (TGREP) Author: M. Bangalore, R. Kumar, J. Rosenberg, H. Salama, D.N. Shah Status: Standards Track Date: March 2008 Mailbox: manjax@cisco.com, rajneesh@cisco.com, jdrosen@cisco.com, hsalama@citexsoftware.com, dhaval@moowee.tv Pages: 28 Characters: 59511 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-iptel-tgrep-09.txt URL: http://www.rfc-editor.org/rfc/rfc5140.txt This document describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. [STANDARDS TRACK] This document is a product of the IP Telephony Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel5224@micm.com.au Wed Mar 12 10:35:33 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B4D28C799 for ; Wed, 12 Mar 2008 10:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.415 X-Spam-Level: X-Spam-Status: No, score=-28.415 tagged_above=-999 required=5 tests=[AWL=-35.087, BAYES_99=3.5, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SARE_RECV_IP_083028=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 kpx1BnrOQliO for ; Wed, 12 Mar 2008 10:35:33 -0700 (PDT) Received: from bdw121.neoplus.adsl.tpnet.pl (bdw121.neoplus.adsl.tpnet.pl [83.28.8.121]) by core3.amsl.com (Postfix) with SMTP id 8032F3A6EFF for ; Wed, 12 Mar 2008 10:35:01 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20080312073241.10739.qmail@bdw121.neoplus.adsl.tpnet.pl> To: Subject: RE: MensHealth id 961755 From: MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 12 Mar 2008 10:35:01 -0700 (PDT) Your Alert!!
From alloyingm12@simonwaller.com Mon Mar 17 00:53:28 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13CC93A6CE1; Mon, 17 Mar 2008 00:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.886 X-Spam-Level: **** X-Spam-Status: No, score=4.886 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DOS_OE_TO_MX=2.75, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcAjz8ZjTnfa; Mon, 17 Mar 2008 00:53:27 -0700 (PDT) Received: from gmz.gorlovka.net (gmz.gorlovka.net [194.44.79.42]) by core3.amsl.com (Postfix) with ESMTP id 9BFC23A6DFF; Mon, 17 Mar 2008 00:52:12 -0700 (PDT) Message-ID: <01c88814$434e7d80$2a4f2cc2@alloyingm12> From: "Geoffrey Childs" To: Subject: Groove 2007 Date: Mon, 17 Mar 2008 09:49:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam: Not detected X-Antivirus: avast! (VPS 080316-0, 16.03.2008), Outbound message X-Antivirus-Status: Clean Microsoft Office Enterprise 2007 includes: • Access 2007 • Communicator 2007 • Excel 2007 • Groove 2007 • InfoPath 2007 • OneNote 2007 • Outlook 2007 • PowerPoint 2007 • Publisher 2007 • Word 2007 http://kirstencumpstont960.blogspot.com System Requirements • Intel® Pentium® or AMD® 500 MHz processor • Microsoft Windows® XP Professional or Home Edition with Service Pack 2, Windows Server® 2003 with SP1 , Microsoft Windows Vista. • 256 Mb of RAM • 2GB of available hard-disk space. • 1024x768 or higher resolution monitor • Some features require Microsoft Windows Desktop Search 3.0, Microsoft Windows Media Player 9.0, Microsoft DirectX 9.0b, Microsoft Active Sync 4.1 From moultsk@cohenlawfirm.com Mon Mar 17 01:38:41 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345603A6CD2; Mon, 17 Mar 2008 01:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.406 X-Spam-Level: **** X-Spam-Status: No, score=4.406 tagged_above=-999 required=5 tests=[BAYES_99=3.5, RCVD_IN_PBL=0.905, STOX_REPLY_TYPE=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 C67RVLxm7gAy; Mon, 17 Mar 2008 01:38:40 -0700 (PDT) Received: from 178-186.un.vitebsk.by (178-186.un.vitebsk.by [86.57.178.186]) by core3.amsl.com (Postfix) with ESMTP id BEF523A6C5C; Mon, 17 Mar 2008 01:38:39 -0700 (PDT) Received: from [86.57.178.186] by mail.cohenlawfirm.com; Mon, 17 Mar 2008 10:36:23 +0200 Message-ID: <01c8881a$beb32d80$bab23956@moultsk> From: "Effie Camp" To: Subject: Increase in Girth (Width) of 10%. Date: Mon, 17 Mar 2008 10:36:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1250"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2741.2600 Over 1,500,000 bottles sold worldwide. http://miriamshrinerdf251.blogspot.com From iptel-bounces@ietf.org Tue Mar 25 14:45:49 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D62E28C58C; Tue, 25 Mar 2008 14:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 vnSre5e+kD01; Tue, 25 Mar 2008 14:45:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B26228C4F0; Tue, 25 Mar 2008 14:45:11 -0700 (PDT) X-Original-To: iptel@ietf.org Delivered-To: iptel@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D080028C47B; Tue, 25 Mar 2008 14:45:01 -0700 (PDT) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080325214501.D080028C47B@core3.amsl.com> Date: Tue, 25 Mar 2008 14:45:01 -0700 (PDT) Cc: iptel@ietf.org Subject: [Iptel] I-D Action:draft-ietf-iptel-tel-reg-05.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry Author(s) : C. Jennings, V. Gurbani Filename : draft-ietf-iptel-tel-reg-05.txt Pages : 8 Date : 2008-03-25 This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-iptel-tel-reg-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-03-25143230.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --NextPart-- From iptel-bounces@ietf.org Tue Mar 25 14:50:50 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F266928C5FC; Tue, 25 Mar 2008 14:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.691 X-Spam-Level: X-Spam-Status: No, score=-100.691 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfOFyyxfmWLA; Tue, 25 Mar 2008 14:50:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26BAE28C529; Tue, 25 Mar 2008 14:50:45 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9DF28C429 for ; Tue, 25 Mar 2008 14:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3pZb21aDhJd for ; Tue, 25 Mar 2008 14:50:39 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 078D73A69BE for ; Tue, 25 Mar 2008 14:50:20 -0700 (PDT) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m2PLlu1s015683; Tue, 25 Mar 2008 16:47:56 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m2PLluA06063; Tue, 25 Mar 2008 16:47:56 -0500 (CDT) Message-ID: <47E9730C.1060709@alcatel-lucent.com> Date: Tue, 25 Mar 2008 16:47:56 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF IPTEL WG X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [Iptel] Updated version of iptel-tel-reg X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Folks: For those of you who have been waiting patiently for the tel URI registry to get established, the wait is over ;-) Those of you who have been waiting even patiently for iptel to close down, the wait is also over ;-) I think Cullen and I will share the dubious distinction of producing the last RFC in iptel WG -- iptel-tel-reg. The -05 version of iptel-tel-reg has been released. I believe that this version accurately encapsulates the debate that ensued between "Standards Action" and "Specification Required, Designated Expert". As per the instructions from Jon, I have updated S4.2 to include the latter policy, along with some criteria to consider when expert reviewing a tel URI parameter. I have included various comments Jon pointed out during his AD review of this draft (11 months ago!), including changing the phrase "accompanying RFC" to "accompanying RFC or other permanent and readily available public specification" to reflect the designation of "Specification Required." The new draft is available at http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt and a diff between -04 and -05 is at: http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-04.txt&url2=http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt Please let me know if there are any additional comments. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 27 01:00:50 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D579628C333; Thu, 27 Mar 2008 01:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.252 X-Spam-Level: X-Spam-Status: No, score=-100.252 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urBTReqE0Hd2; Thu, 27 Mar 2008 01:00:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ABD63A6A1A; Thu, 27 Mar 2008 01:00:49 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111B328C7E1 for ; Thu, 27 Mar 2008 01:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjZxXy9m80KV for ; Thu, 27 Mar 2008 01:00:47 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id A40643A6BCC for ; Thu, 27 Mar 2008 01:00:00 -0700 (PDT) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.15020562; Thu, 27 Mar 2008 03:57:17 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Mar 2008 03:57:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 03:56:22 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602043FCC34@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQ== From: "Lee, Yiu" To: , X-OriginalArrivalTime: 27 Mar 2008 07:57:17.0197 (UTC) FILETIME=[2D16BBD0:01C88FE0] Subject: [Iptel] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2078908249==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============2078908249== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C88FE0.2CF12304" This is a multi-part message in MIME format. ------_=_NextPart_001_01C88FE0.2CF12304 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG item? If not, is there any other standard way to carry CPC or OLI parameter in SIP?=20 Thanks, Yiu ------_=_NextPart_001_01C88FE0.2CF12304 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc

Hi,

This draft = (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG = item? If not, is there any other standard way to carry CPC or OLI = parameter in SIP?

Thanks,
Yiu

------_=_NextPart_001_01C88FE0.2CF12304-- --===============2078908249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============2078908249==-- From iptel-bounces@ietf.org Thu Mar 27 05:07:03 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E248B3A6A42; Thu, 27 Mar 2008 05:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.023 X-Spam-Level: X-Spam-Status: No, score=-101.023 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc2KsN9WiESX; Thu, 27 Mar 2008 05:07:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0306D3A6B77; Thu, 27 Mar 2008 05:07:02 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018F33A6A42 for ; Thu, 27 Mar 2008 05:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8SU+knM0ifk for ; Thu, 27 Mar 2008 05:07:01 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id D8B7B3A6996 for ; Thu, 27 Mar 2008 05:07:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-6.tower-203.messagelabs.com!1206619475!10956897!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 18511 invoked from network); 27 Mar 2008 12:04:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 27 Mar 2008 12:04:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2RC4IwD017241 for ; Thu, 27 Mar 2008 08:04:18 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2RC48O9017149 for ; Thu, 27 Mar 2008 08:04:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 07:04:08 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246ED1D@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <45AEC6EF95942140888406588E1A6602043FCC34@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJyw References: <45AEC6EF95942140888406588E1A6602043FCC34@PACDCEXCMB04.cable.comcast.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Lee, Yiu" , , Subject: Re: [Iptel] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1111250366==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============1111250366== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89002.A90E4599" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89002.A90E4599 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yiu, =20 There is not a standard way to pass CPC or OLI in SIP? Also, draft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment needs because it blends CPC and OLI. =20 Martin ________________________________ From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Lee, Yiu Sent: Thursday, March 27, 2008 3:56 AM To: iptel@ietf.org; rohan@ekabal.com Subject: [Iptel] draft-mahy-iptel-cpc Hi,=20 This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG item? If not, is there any other standard way to carry CPC or OLI parameter in SIP?=20 Thanks,=20 Yiu=20 ------_=_NextPart_001_01C89002.A90E4599 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc
Yiu,
 
There is not a standard way to pass CPC or OLI = in SIP?=20 Also, draft-mahy-iptel-cpc-06.txt would not meet = Nroth=20 American deployment needs because it blends CPC and=20 OLI.
 
Martin

From: iptel-bounces@ietf.org=20 [mailto:iptel-bounces@ietf.org] On Behalf Of Lee, = Yiu
Sent:=20 Thursday, March 27, 2008 3:56 AM
To: iptel@ietf.org;=20 rohan@ekabal.com
Subject: [Iptel]=20 draft-mahy-iptel-cpc

Hi,

This draft (draft-mahy-iptel-cpc-06.txt) = is expired.=20 Will this draft become WG item? If not, is there any other standard way = to carry=20 CPC or OLI parameter in SIP?

Thanks,
Yiu=20

------_=_NextPart_001_01C89002.A90E4599-- --===============1111250366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============1111250366==-- From iptel-bounces@ietf.org Thu Mar 27 06:49:03 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9813A6F92; Thu, 27 Mar 2008 06:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.542 X-Spam-Level: X-Spam-Status: No, score=-100.542 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVALZTsREBlo; Thu, 27 Mar 2008 06:48:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B9428C639; Thu, 27 Mar 2008 06:48:57 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E1A728C1FE; Thu, 27 Mar 2008 06:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3xCZ2HbOoO3; Thu, 27 Mar 2008 06:48:51 -0700 (PDT) Received: from MAILSRV01.cedarpointcom.com (mail.cedarpointcom.com [67.151.79.70]) by core3.amsl.com (Postfix) with ESMTP id 864AB3A6FDF; Thu, 27 Mar 2008 06:48:50 -0700 (PDT) Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Mar 2008 09:46:29 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Mar 2008 09:46:37 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F0212F250@MAIL02.cedarpointcom.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED1D@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+A= References: <45AEC6EF95942140888406588E1A6602043FCC34@PACDCEXCMB04.cable.comcast.com> <28F05913385EAC43AF019413F674A0171246ED1D@OCCLUST04EVS1.ugd.att.com> From: "Sumit Garg" To: , X-OriginalArrivalTime: 27 Mar 2008 13:46:29.0788 (UTC) FILETIME=[F5CE65C0:01C89010] Subject: Re: [Iptel] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0783990058==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0783990058== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89010.F60D1CFC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89010.F60D1CFC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Over a period of time I have seen various efforts in that direction which eventually get dropped...to list a few: draft-schubert-sipping-saml-cpc-02.txt (Expired: jan 2007) draft-mahy-iptel-cpc-06.txt (Expired:Sep 2007) draft-ietf-sip-privacy-04.txt , Appendix A (Expired: 2002) draft-rocky-sipping-calling-party-category-01.txt (Expired : 2006) =20 I've also seen implementation using parameters like isup-oli for which I could not even find a draft. =20 Based on this I believe conveying CPC/OLI in SIP is a real requirement. Maybe for pure SIP scenario it could be done with caller-preferences, but not in interworking scenarios. =20 From what I understand: 1. CPC in ISUP could be desired by the terminating exchange, however, the scope of the OLI is only 1 call-leg and could be different from CPC as it is more closely tied to the billing number. 3. CPC is ISUP only, OLI could be over MF also. =20 I don't really care what the tag-name in use is (oli/cpc)but, from where I am looking I would say: 1. cpc-param in P-Asserted-Id corresponds to cpc in ISUP (Better than in From header as it is a tel-uri parameter). 2. cpc-param in History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could correspond to OLI. =20 Is there some way of reaching consensus and moving on...rather than have more aborted attempts in the future? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Thursday, March 27, 2008 8:04 AM To: Lee, Yiu; iptel@ietf.org; rohan@ekabal.com Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Yiu, =20 There is not a standard way to pass CPC or OLI in SIP? Also, draft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment needs because it blends CPC and OLI. =20 Martin =20 ________________________________ From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Lee, Yiu Sent: Thursday, March 27, 2008 3:56 AM To: iptel@ietf.org; rohan@ekabal.com Subject: [Iptel] draft-mahy-iptel-cpc Hi,=20 This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG item? If not, is there any other standard way to carry CPC or OLI parameter in SIP?=20 Thanks,=20 Yiu=20 ------_=_NextPart_001_01C89010.F60D1CFC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc

Over a period of time I have seen various efforts in that direction which eventually get dropped…to list a = few:

draft-schubert-sipping-saml-cpc-02.txt (Expired: jan = 2007)

draft-mahy-iptel-cpc-06.txt (Expired:Sep = 2007)

draft-ietf-sip-privacy-04.txt , Appendix A (Expired: = 2002)

draft-rocky-sipping-calling-party-category-01.txt = (Expired : 2006)

 

I’ve also seen implementation using parameters =  like isup-oli for which I could not even find a draft.

 

Based on this I believe conveying CPC/OLI in SIP is a = real requirement.

Maybe for pure SIP scenario it could be done with caller-preferences, but not in interworking = scenarios.

 

From what I understand:

1. CPC in ISUP could be desired by the terminating = exchange, however, the scope of the OLI is only 1 call-leg and could be different = from CPC as it is more closely tied to the billing number.

3. CPC is ISUP only, OLI could be over MF = also.

 

I don’t really care what the tag-name in use is = (oli/cpc)but, from where I am looking I would say:

1.       cpc-param in P-Asserted-Id corresponds to cpc in ISUP = (Better than in From header as it is a tel-uri parameter).

2.       cpc-param in = History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could correspond to OLI.

 

Is there some way of reaching consensus and moving = on…rather than have more aborted attempts in the future?

 

-Sumit

 

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From:= iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = DOLLY, MARTIN C, ATTLABS
Sent: Thursday, March 27, 2008 8:04 AM
To: Lee, Yiu; iptel@ietf.org; rohan@ekabal.com
Subject: Re: [Iptel] draft-mahy-iptel-cpc

 

Yiu,

 

There is not a standard way to pass CPC or OLI in SIP? Also, = d= raft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment needs because it blends CPC and = OLI.

 

Martin=

 

From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Lee, Yiu
Sent: Thursday, March 27, 2008 3:56 AM
To: iptel@ietf.org; rohan@ekabal.com
Subject: [Iptel] draft-mahy-iptel-cpc

Hi, =

This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG = item? If not, is there any other standard way to carry CPC or OLI parameter in = SIP?

Thanks,
Yiu =

------_=_NextPart_001_01C89010.F60D1CFC-- --===============0783990058== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============0783990058==-- From iptel-bounces@ietf.org Fri Mar 28 06:15:07 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A873C28C92A; Fri, 28 Mar 2008 06:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.867 X-Spam-Level: X-Spam-Status: No, score=-97.867 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf2GGbQCQdmG; Fri, 28 Mar 2008 06:14:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB65A28C950; Fri, 28 Mar 2008 06:14:28 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00D728C93F; Fri, 28 Mar 2008 06:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl7O7ZX86N+V; Fri, 28 Mar 2008 06:14:09 -0700 (PDT) Received: from MAILSRV01.cedarpointcom.com (mail.cedarpointcom.com [67.151.79.70]) by core3.amsl.com (Postfix) with ESMTP id 19D7328C25F; Fri, 28 Mar 2008 06:12:57 -0700 (PDT) Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Mar 2008 09:12:42 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 09:12:43 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F0212F59B@MAIL02.cedarpointcom.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F0212F250@MAIL02.cedarpointcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkA== References: <45AEC6EF95942140888406588E1A6602043FCC34@PACDCEXCMB04.cable.comcast.com><28F05913385EAC43AF019413F674A0171246ED1D@OCCLUST04EVS1.ugd.att.com> <59184B4E920E854DA8ACF8E44917D49F0212F250@MAIL02.cedarpointcom.com> From: "Sumit Garg" To: , X-OriginalArrivalTime: 28 Mar 2008 13:12:42.0814 (UTC) FILETIME=[680C75E0:01C890D5] Subject: Re: [Iptel] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0816896420==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0816896420== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C890D5.67D1F112" This is a multi-part message in MIME format. ------_=_NextPart_001_01C890D5.67D1F112 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was surprised by the lack of responses. This is a real need as I believe intermediate exchanges could need special processing for calls from Prison etc. =20 The reason I proposed using P-A-I as opposed to From header in the draft was: In case of anonymous calls, the From header is generally of the form anonymous@....... A derived tel-Uri with cpc would look like anonymous;cpc=3Dpayphone =20 This violates the tel-URI syntax. P-Asserted-Id covers this scenario as well. =20 If there is a defined standard mechanism for this requirement, could somebody please point me to the same? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Sumit Garg Sent: Thursday, March 27, 2008 9:47 AM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Over a period of time I have seen various efforts in that direction which eventually get dropped...to list a few: draft-schubert-sipping-saml-cpc-02.txt (Expired: jan 2007) draft-mahy-iptel-cpc-06.txt (Expired:Sep 2007) draft-ietf-sip-privacy-04.txt , Appendix A (Expired: 2002) draft-rocky-sipping-calling-party-category-01.txt (Expired : 2006) =20 I've also seen implementation using parameters like isup-oli for which I could not even find a draft. =20 Based on this I believe conveying CPC/OLI in SIP is a real requirement. Maybe for pure SIP scenario it could be done with caller-preferences, but not in interworking scenarios. =20 From what I understand: 1. CPC in ISUP could be desired by the terminating exchange, however, the scope of the OLI is only 1 call-leg and could be different from CPC as it is more closely tied to the billing number. 3. CPC is ISUP only, OLI could be over MF also. =20 I don't really care what the tag-name in use is (oli/cpc)but, from where I am looking I would say: 1. cpc-param in P-Asserted-Id corresponds to cpc in ISUP (Better than in From header as it is a tel-uri parameter). 2. cpc-param in History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could correspond to OLI. =20 Is there some way of reaching consensus and moving on...rather than have more aborted attempts in the future? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Thursday, March 27, 2008 8:04 AM To: Lee, Yiu; iptel@ietf.org; rohan@ekabal.com Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Yiu, =20 There is not a standard way to pass CPC or OLI in SIP? Also, draft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment needs because it blends CPC and OLI. =20 Martin =20 ________________________________ From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Lee, Yiu Sent: Thursday, March 27, 2008 3:56 AM To: iptel@ietf.org; rohan@ekabal.com Subject: [Iptel] draft-mahy-iptel-cpc Hi,=20 This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG item? If not, is there any other standard way to carry CPC or OLI parameter in SIP?=20 Thanks,=20 Yiu=20 ------_=_NextPart_001_01C890D5.67D1F112 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc

I was surprised by the lack of = responses.

This is a real need as I believe intermediate exchanges = could need special processing for calls from Prison etc.

 

The reason I proposed using P-A-I as opposed to From = header in the draft was:

In case of anonymous calls, the From header is generally = of the form anonymous@.......

A derived tel-Uri with cpc would look like = anonymous;cpc=3Dpayphone

 

This violates the tel-URI syntax. P-Asserted-Id covers = this scenario as well.

 

If there is a defined standard mechanism for this = requirement, could somebody please point me to the same?

 

-Sumit

 

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From:= iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = Sumit Garg
Sent: Thursday, March 27, 2008 9:47 AM
To: iptel@ietf.org; sipping@ietf.org
Subject: Re: [Iptel] draft-mahy-iptel-cpc

 

Over a period of time I have seen various efforts in that direction which eventually get dropped…to list a = few:

draft-schubert-sipping-saml-cpc-02.txt (Expired: jan = 2007)

draft-mahy-iptel-cpc-06.txt (Expired:Sep = 2007)

draft-ietf-sip-privacy-04.txt , Appendix A (Expired: = 2002)

draft-rocky-sipping-calling-party-category-01.txt = (Expired : 2006)

 

I’ve also seen implementation using parameters =  like isup-oli for which I could not even find a draft.

 

Based on this I believe conveying CPC/OLI in SIP is a = real requirement.

Maybe for pure SIP scenario it could be done with caller-preferences, but not in interworking = scenarios.

 

From what I understand:

1. CPC in ISUP could be desired by the terminating = exchange, however, the scope of the OLI is only 1 call-leg and could be different = from CPC as it is more closely tied to the billing = number.

3. CPC is ISUP only, OLI could be over MF = also.

 

I don’t really care what the tag-name in use is (oli/cpc)but, from where I am looking I would say:

1.       cpc-param in P-Asserted-Id corresponds to cpc in ISUP = (Better than in From header as it is a tel-uri parameter).

2.       cpc-param in = History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could correspond to OLI.

 

Is there some way of reaching consensus and moving on…rather than have more aborted attempts in the = future?

 

-Sumit

 

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From:= iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = DOLLY, MARTIN C, ATTLABS
Sent: Thursday, March 27, 2008 8:04 AM
To: Lee, Yiu; iptel@ietf.org; rohan@ekabal.com
Subject: Re: [Iptel] draft-mahy-iptel-cpc

 

Yiu,

 

There is not a standard way to pass CPC or OLI in SIP? Also, = d= raft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment needs because it blends CPC and = OLI.

 

Martin=

 

From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Lee, Yiu
Sent: Thursday, March 27, 2008 3:56 AM
To: iptel@ietf.org; rohan@ekabal.com
Subject: [Iptel] draft-mahy-iptel-cpc

Hi, =

This draft = (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG item? If not, is there any other = standard way to carry CPC or OLI parameter in SIP?

Thanks,
Yiu =

------_=_NextPart_001_01C890D5.67D1F112-- --===============0816896420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============0816896420==-- From iptel-bounces@ietf.org Fri Mar 28 06:54:33 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D2028C923; Fri, 28 Mar 2008 06:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.538 X-Spam-Level: X-Spam-Status: No, score=-100.538 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s+tFeRpjQTb; Fri, 28 Mar 2008 06:54:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8049728C965; Fri, 28 Mar 2008 06:53:48 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE5128C2C0; Fri, 28 Mar 2008 06:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i09zIYGdz+jb; Fri, 28 Mar 2008 06:53:39 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id E36BE28C9B8; Fri, 28 Mar 2008 06:50:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-13.tower-203.messagelabs.com!1206712205!11140818!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 5422 invoked from network); 28 Mar 2008 13:50:06 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2008 13:50:06 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2SDo9ua031749; Fri, 28 Mar 2008 09:50:10 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2SDo34G031664; Fri, 28 Mar 2008 09:50:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 08:50:02 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246ED39@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F0212F59B@MAIL02.cedarpointcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkAABXNtA References: <45AEC6EF95942140888406588E1A6602043FCC34@PACDCEXCMB04.cable.comcast.com><28F05913385EAC43AF019413F674A0171246ED1D@OCCLUST04EVS1.ugd.att.com><59184B4E920E854DA8ACF8E44917D49F0212F250@MAIL02.cedarpointcom.com> <59184B4E920E854DA8ACF8E44917D49F0212F59B@MAIL02.cedarpointcom.com> From: "DOLLY, MARTIN C, sbcuid" To: "Sumit Garg" , , Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0818872018==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0818872018== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C890DA.9F3F21BA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C890DA.9F3F21BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sumit, =20 What is really needed is OLI & CPC for North American deployments. Prisons is an OLI value, not a CPC value. That is the issue with the cpc draft it mixes up two different parameters. OLI is what type of line, where CPC is call type ( for the most part). =20 Martin ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit Garg Sent: Friday, March 28, 2008 9:13 AM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc I was surprised by the lack of responses. This is a real need as I believe intermediate exchanges could need special processing for calls from Prison etc. =20 The reason I proposed using P-A-I as opposed to From header in the draft was: In case of anonymous calls, the From header is generally of the form anonymous@....... A derived tel-Uri with cpc would look like anonymous;cpc=3Dpayphone =20 This violates the tel-URI syntax. P-Asserted-Id covers this scenario as well. =20 If there is a defined standard mechanism for this requirement, could somebody please point me to the same? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Sumit Garg Sent: Thursday, March 27, 2008 9:47 AM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Over a period of time I have seen various efforts in that direction which eventually get dropped...to list a few: draft-schubert-sipping-saml-cpc-02.txt (Expired: jan 2007) draft-mahy-iptel-cpc-06.txt (Expired:Sep 2007) draft-ietf-sip-privacy-04.txt , Appendix A (Expired: 2002) draft-rocky-sipping-calling-party-category-01.txt (Expired : 2006) =20 I've also seen implementation using parameters like isup-oli for which I could not even find a draft. =20 Based on this I believe conveying CPC/OLI in SIP is a real requirement. Maybe for pure SIP scenario it could be done with caller-preferences, but not in interworking scenarios. =20 From what I understand: 1. CPC in ISUP could be desired by the terminating exchange, however, the scope of the OLI is only 1 call-leg and could be different from CPC as it is more closely tied to the billing number. 3. CPC is ISUP only, OLI could be over MF also. =20 I don't really care what the tag-name in use is (oli/cpc)but, from where I am looking I would say: 1. cpc-param in P-Asserted-Id corresponds to cpc in ISUP (Better than in From header as it is a tel-uri parameter). 2. cpc-param in History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could correspond to OLI. =20 Is there some way of reaching consensus and moving on...rather than have more aborted attempts in the future? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Thursday, March 27, 2008 8:04 AM To: Lee, Yiu; iptel@ietf.org; rohan@ekabal.com Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Yiu, =20 There is not a standard way to pass CPC or OLI in SIP? Also, draft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment needs because it blends CPC and OLI. =20 Martin =20 ________________________________ From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Lee, Yiu Sent: Thursday, March 27, 2008 3:56 AM To: iptel@ietf.org; rohan@ekabal.com Subject: [Iptel] draft-mahy-iptel-cpc Hi,=20 This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG item? If not, is there any other standard way to carry CPC or OLI parameter in SIP?=20 Thanks,=20 Yiu=20 ------_=_NextPart_001_01C890DA.9F3F21BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc
Sumit,
 
What is really needed is OLI & CPC for = North American=20 deployments. Prisons is an OLI value, not a CPC value. That is the issue = with=20 the cpc draft it mixes up two different parameters. OLI is what type of = line,=20 where CPC is call type ( for the most part).
 
Martin

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit = Garg
Sent:=20 Friday, March 28, 2008 9:13 AM
To: iptel@ietf.org;=20 sipping@ietf.org
Subject: Re: [Sipping]=20 draft-mahy-iptel-cpc

I=20 was surprised by the lack of responses.

This=20 is a real need as I believe intermediate exchanges could need special = processing=20 for calls from Prison etc.

 

The=20 reason I proposed using P-A-I as opposed to From header in the draft=20 was:

In=20 case of anonymous calls, the From header is generally of the form=20 anonymous@.......

A=20 derived tel-Uri with cpc would look like=20 anonymous;cpc=3Dpayphone

 

This=20 violates the tel-URI syntax. P-Asserted-Id covers this scenario as=20 well.

 

If=20 there is a defined standard mechanism for this requirement, could = somebody=20 please point me to the same?

 

-Sumit

 

"The reasonable man = adapts=20 himself to the world; the unreasonable one persists in trying to adapt = the world=20 to himself. Therefore all progress depends on the unreasonable = man."
--=20 George Bernard Shaw

From:=20 iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = Sumit=20 Garg
Sent: Thursday, March 27, 2008 9:47 AM
To:=20 iptel@ietf.org; sipping@ietf.org
Subject: Re: [Iptel]=20 draft-mahy-iptel-cpc

 

Over=20 a period of time I have seen various efforts in that direction which = eventually=20 get dropped…to list a few:

draft-schubert-sipping-saml-cpc-02.txt=20 (Expired: jan 2007)

draft-mahy-iptel-cpc-06.txt=20 (Expired:Sep 2007)

draft-ietf-sip-privacy-04.txt=20 , Appendix A (Expired: 2002)

draft-rocky-sipping-calling-party-category-01.txt= =20 (Expired : 2006)

 

I’ve=20 also seen implementation using parameters  like isup-oli for which = I could=20 not even find a draft.

 

Based=20 on this I believe conveying CPC/OLI in SIP is a real=20 requirement.

Maybe=20 for pure SIP scenario it could be done with caller-preferences, but not = in=20 interworking scenarios.

 

From=20 what I understand:

1.=20 CPC in ISUP could be desired by the terminating exchange, however, the = scope of=20 the OLI is only 1 call-leg and could be different from CPC as it is more = closely=20 tied to the billing number.

3.=20 CPC is ISUP only, OLI could be over MF also.

 

I=20 don’t really care what the tag-name in use is (oli/cpc)but, from = where I am=20 looking I would say:

1.      =20 cpc-param=20 in P-Asserted-Id corresponds to cpc in ISUP (Better than in From header = as it is=20 a tel-uri parameter).

2.      =20 cpc-param=20 in History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could = correspond to OLI.

 

Is=20 there some way of reaching consensus and moving on…rather than = have more aborted=20 attempts in the future?

 

-Sumit

 

"The reasonable man = adapts=20 himself to the world; the unreasonable one persists in trying to adapt = the world=20 to himself. Therefore all progress depends on the unreasonable = man."
--=20 George Bernard Shaw

From:=20 iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of=20 DOLLY, MARTIN C, ATTLABS
Sent: Thursday, March 27, 2008 = 8:04=20 AM
To: Lee, Yiu; iptel@ietf.org; = rohan@ekabal.com
Subject:=20 Re: [Iptel] draft-mahy-iptel-cpc

 

Yiu,

 

There is=20 not a standard way to pass CPC or OLI in SIP? Also, draft-mahy-iptel-cpc-06.txt=20 would not meet Nroth American deployment needs because it blends CPC and = OLI.

 

Martin

 

From:=20 iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = Lee,=20 Yiu
Sent: Thursday, March 27, 2008 3:56 AM
To:=20 iptel@ietf.org; rohan@ekabal.com
Subject: [Iptel]=20 draft-mahy-iptel-cpc

Hi,=20

This draft=20 (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG = item? If=20 not, is there any other standard way to carry CPC or OLI parameter in = SIP?=20

Thanks,=20
Yiu=20

------_=_NextPart_001_01C890DA.9F3F21BA-- --===============0818872018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============0818872018==-- From iptel-bounces@ietf.org Fri Mar 28 07:04:47 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D26928C922; Fri, 28 Mar 2008 07:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.611 X-Spam-Level: X-Spam-Status: No, score=-100.611 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny4lUyzdGS84; Fri, 28 Mar 2008 07:04:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBBE228C10C; Fri, 28 Mar 2008 07:04:35 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA49628C2CB for ; Fri, 28 Mar 2008 07:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUbtUrkPEfo0 for ; Fri, 28 Mar 2008 07:04:25 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id A0B713A6E24 for ; Fri, 28 Mar 2008 07:04:24 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP for iptel@ietf.org; Fri, 28 Mar 2008 15:04:23 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Mar 2008 15:04:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 15:04:22 +0100 Message-Id: <9886E5FCA6D76549A3011068483A4BD4023298F5@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkAABXNtAAAB7UjAAAEGwcA== From: "Jesske, R" To: X-OriginalArrivalTime: 28 Mar 2008 14:04:23.0275 (UTC) FILETIME=[A01143B0:01C890DC] Subject: [Iptel] WG: [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0488648811==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0488648811== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C890DC.9FE70604" This is a multi-part message in MIME format. ------_=_NextPart_001_01C890DC.9FE70604 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, nevertheless what is the status now of cpc? Because cpc is needed in = some cases like ieps of payphone. And we could add the OLI. =20 Thanks and Best Regards =20 Roland ________________________________ Von: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] Im = Auftrag von DOLLY, MARTIN C, sbcuid Gesendet: Freitag, 28. M=E4rz 2008 14:50 An: Sumit Garg; iptel@ietf.org; sipping@ietf.org Betreff: Re: [Sipping] draft-mahy-iptel-cpc =09 =09 Sumit, =20 What is really needed is OLI & CPC for North American deployments. = Prisons is an OLI value, not a CPC value. That is the issue with the cpc = draft it mixes up two different parameters. OLI is what type of line, = where CPC is call type ( for the most part). =20 Martin ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On = Behalf Of Sumit Garg Sent: Friday, March 28, 2008 9:13 AM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc =09 =09 I was surprised by the lack of responses. This is a real need as I believe intermediate exchanges could need = special processing for calls from Prison etc. =20 The reason I proposed using P-A-I as opposed to From header in the = draft was: In case of anonymous calls, the From header is generally of the form = anonymous@....... A derived tel-Uri with cpc would look like anonymous;cpc=3Dpayphone =20 This violates the tel-URI syntax. P-Asserted-Id covers this scenario as = well. =20 If there is a defined standard mechanism for this requirement, could = somebody please point me to the same? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one = persists in trying to adapt the world to himself. Therefore all progress = depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf = Of Sumit Garg Sent: Thursday, March 27, 2008 9:47 AM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Over a period of time I have seen various efforts in that direction = which eventually get dropped...to list a few: draft-schubert-sipping-saml-cpc-02.txt (Expired: jan 2007) draft-mahy-iptel-cpc-06.txt (Expired:Sep 2007) draft-ietf-sip-privacy-04.txt , Appendix A (Expired: 2002) draft-rocky-sipping-calling-party-category-01.txt (Expired : 2006) =20 I've also seen implementation using parameters like isup-oli for which = I could not even find a draft. =20 Based on this I believe conveying CPC/OLI in SIP is a real requirement. Maybe for pure SIP scenario it could be done with caller-preferences, = but not in interworking scenarios. =20 From what I understand: 1. CPC in ISUP could be desired by the terminating exchange, however, = the scope of the OLI is only 1 call-leg and could be different from CPC = as it is more closely tied to the billing number. 3. CPC is ISUP only, OLI could be over MF also. =20 I don't really care what the tag-name in use is (oli/cpc)but, from = where I am looking I would say: 1. cpc-param in P-Asserted-Id corresponds to cpc in ISUP (Better = than in From header as it is a tel-uri parameter). 2. cpc-param in = History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could = correspond to OLI. =20 Is there some way of reaching consensus and moving on...rather than = have more aborted attempts in the future? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one = persists in trying to adapt the world to himself. Therefore all progress = depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf = Of DOLLY, MARTIN C, ATTLABS Sent: Thursday, March 27, 2008 8:04 AM To: Lee, Yiu; iptel@ietf.org; rohan@ekabal.com Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Yiu, =20 There is not a standard way to pass CPC or OLI in SIP? Also, = draft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment = needs because it blends CPC and OLI. =20 Martin =20 ________________________________ From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf = Of Lee, Yiu Sent: Thursday, March 27, 2008 3:56 AM To: iptel@ietf.org; rohan@ekabal.com Subject: [Iptel] draft-mahy-iptel-cpc Hi,=20 This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft = become WG item? If not, is there any other standard way to carry CPC or = OLI parameter in SIP?=20 Thanks,=20 Yiu=20 ------_=_NextPart_001_01C890DC.9FE70604 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc
Hi,
nevertheless what is the status now of cpc? = Because cpc is=20 needed in some cases like ieps of payphone.
And we could add the OLI.
 
Thanks and Best Regards
 
Roland

Von: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN = C,=20 sbcuid
Gesendet: Freitag, 28. März 2008 = 14:50
An: Sumit=20 Garg; iptel@ietf.org; sipping@ietf.org
Betreff: Re: = [Sipping]=20 draft-mahy-iptel-cpc

Sumit,
 
What is really needed is OLI & CPC for = North American=20 deployments. Prisons is an OLI value, not a CPC value. That is the = issue with=20 the cpc draft it mixes up two different parameters. OLI is what type = of line,=20 where CPC is call type ( for the most part).
 
Martin

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit=20 Garg
Sent: Friday, March 28, 2008 9:13 AM
To:=20 iptel@ietf.org; sipping@ietf.org
Subject: Re: [Sipping]=20 draft-mahy-iptel-cpc

I=20 was surprised by the lack of responses.

This=20 is a real need as I believe intermediate exchanges could need special=20 processing for calls from Prison etc.

 

The=20 reason I proposed using P-A-I as opposed to From header in the draft=20 was:

In=20 case of anonymous calls, the From header is generally of the form=20 anonymous@.......

A=20 derived tel-Uri with cpc would look like=20 anonymous;cpc=3Dpayphone

 

This=20 violates the tel-URI syntax. P-Asserted-Id covers this scenario as=20 well.

 

If=20 there is a defined standard mechanism for this requirement, could = somebody=20 please point me to the same?

 

-Sumit

 

"The reasonable = man adapts=20 himself to the world; the unreasonable one persists in trying to adapt = the=20 world to himself. Therefore all progress depends on the unreasonable=20 man."
-- George Bernard Shaw

From:=20 iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = Sumit Garg
Sent: Thursday, March 27, 2008 9:47 = AM
To:=20 iptel@ietf.org; sipping@ietf.org
Subject: Re: [Iptel]=20 draft-mahy-iptel-cpc

 

Over=20 a period of time I have seen various efforts in that direction which=20 eventually get dropped…to list a few:

draft-schubert-sipping-saml-cpc-02.txt=20 (Expired: jan 2007)

draft-mahy-iptel-cpc-06.txt=20 (Expired:Sep 2007)

draft-ietf-sip-privacy-04.txt=20 , Appendix A (Expired: 2002)

draft-rocky-sipping-calling-party-category-01.txt= =20 (Expired : 2006)

 

I’ve=20 also seen implementation using parameters  like isup-oli for = which I=20 could not even find a draft.

 

Based=20 on this I believe conveying CPC/OLI in SIP is a real=20 requirement.

Maybe=20 for pure SIP scenario it could be done with caller-preferences, but = not in=20 interworking scenarios.

 

From=20 what I understand:

1.=20 CPC in ISUP could be desired by the terminating exchange, however, the = scope=20 of the OLI is only 1 call-leg and could be different from CPC as it is = more=20 closely tied to the billing number.

3.=20 CPC is ISUP only, OLI could be over MF also.

 

I=20 don’t really care what the tag-name in use is (oli/cpc)but, = from where I am=20 looking I would say:

1.      =20 cpc-param=20 in P-Asserted-Id corresponds to cpc in ISUP (Better than in From = header as it=20 is a tel-uri parameter).

2.      =20 cpc-param=20 in History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. = could=20 correspond to OLI.

 

Is=20 there some way of reaching consensus and moving on…rather than = have more=20 aborted attempts in the future?

 

-Sumit

 

"The reasonable = man adapts=20 himself to the world; the unreasonable one persists in trying to adapt = the=20 world to himself. Therefore all progress depends on the unreasonable=20 man."
-- George Bernard Shaw

From:=20 iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = DOLLY, MARTIN C, ATTLABS
Sent: Thursday, March 27, 2008 = 8:04=20 AM
To: Lee, Yiu; iptel@ietf.org; = rohan@ekabal.com
Subject:=20 Re: [Iptel] draft-mahy-iptel-cpc

 

Yiu,

 

There=20 is not a standard way to pass CPC or OLI in SIP? Also, draft-mahy-iptel-cpc-06.txt=20 would not meet Nroth American deployment needs because it blends CPC = and=20 OLI.

 

Martin

 

From:=20 iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = Lee, Yiu
Sent: Thursday, March 27, 2008 3:56 = AM
To:=20 iptel@ietf.org; rohan@ekabal.com
Subject: [Iptel]=20 draft-mahy-iptel-cpc

Hi,=20

This draft=20 (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG = item? If=20 not, is there any other standard way to carry CPC or OLI parameter in = SIP?=20

Thanks,=20
Yiu=20

------_=_NextPart_001_01C890DC.9FE70604-- --===============0488648811== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============0488648811==-- From iptel-bounces@ietf.org Fri Mar 28 08:24:23 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BF0E3A6FE0; Fri, 28 Mar 2008 08:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.423 X-Spam-Level: X-Spam-Status: No, score=-99.423 tagged_above=-999 required=5 tests=[AWL=1.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRLVK9mKWHxO; Fri, 28 Mar 2008 08:24:05 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B7B28C992; Fri, 28 Mar 2008 08:24:03 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23CA28C1CF; Fri, 28 Mar 2008 08:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrj1zTLm9p2t; Fri, 28 Mar 2008 08:23:51 -0700 (PDT) Received: from MAILSRV01.cedarpointcom.com (mail.cedarpointcom.com [67.151.79.70]) by core3.amsl.com (Postfix) with ESMTP id 438803A6BB9; Fri, 28 Mar 2008 08:23:51 -0700 (PDT) Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Mar 2008 11:23:49 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 11:23:51 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F0212F66D@MAIL02.cedarpointcom.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4023298EE@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkAABXNtAAAB7UjAAAviUEA== References: <45AEC6EF95942140888406588E1A6602043FCC34@PACDCEXCMB04.cable.comcast.com><28F05913385EAC43AF019413F674A0171246ED1D@OCCLUST04EVS1.ugd.att.com><59184B4E920E854DA8ACF8E44917D49F0212F250@MAIL02.cedarpointcom.com><59184B4E920E854DA8ACF8E44917D49F0212F59B@MAIL02.cedarpointcom.com> <28F05913385EAC43AF019413F674A0171246ED39@OCCLUST04EVS1.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD4023298EE@S4DE8PSAAQB.mitte.t-com.de> From: "Sumit Garg" To: , X-OriginalArrivalTime: 28 Mar 2008 15:23:49.0666 (UTC) FILETIME=[B90ED020:01C890E7] Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0318840203==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0318840203== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C890E7.B8513B22" This is a multi-part message in MIME format. ------_=_NextPart_001_01C890E7.B8513B22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If people agree on the need, and mixed usage is the only road-block what = is preventing us from having 2 parameters.....maybe in the next version = of the draft? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one = persists in trying to adapt the world to himself. Therefore all progress = depends on the unreasonable man." -- George Bernard Shaw From: Jesske, R [mailto:R.Jesske@telekom.de]=20 Sent: Friday, March 28, 2008 9:58 AM To: mdolly@att.com; Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: AW: [Sipping] draft-mahy-iptel-cpc =20 Hi, nevertheless what is the status now of cpc? Because cpc is needed in = some cases like ieps of payphone. And we could add the OLI. =20 Thanks and Best Regards =20 Roland =20 =09 ________________________________ Von: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] Im = Auftrag von DOLLY, MARTIN C, sbcuid Gesendet: Freitag, 28. M=E4rz 2008 14:50 An: Sumit Garg; iptel@ietf.org; sipping@ietf.org Betreff: Re: [Sipping] draft-mahy-iptel-cpc Sumit, =20 What is really needed is OLI & CPC for North American deployments. = Prisons is an OLI value, not a CPC value. That is the issue with the cpc = draft it mixes up two different parameters. OLI is what type of line, = where CPC is call type ( for the most part). =20 Martin =20 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On = Behalf Of Sumit Garg Sent: Friday, March 28, 2008 9:13 AM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc I was surprised by the lack of responses. This is a real need as I believe intermediate exchanges could need = special processing for calls from Prison etc. =20 The reason I proposed using P-A-I as opposed to From header in the = draft was: In case of anonymous calls, the From header is generally of the form = anonymous@....... A derived tel-Uri with cpc would look like anonymous;cpc=3Dpayphone =20 This violates the tel-URI syntax. P-Asserted-Id covers this scenario as = well. =20 If there is a defined standard mechanism for this requirement, could = somebody please point me to the same? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one = persists in trying to adapt the world to himself. Therefore all progress = depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf = Of Sumit Garg Sent: Thursday, March 27, 2008 9:47 AM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Over a period of time I have seen various efforts in that direction = which eventually get dropped...to list a few: draft-schubert-sipping-saml-cpc-02.txt (Expired: jan 2007) draft-mahy-iptel-cpc-06.txt (Expired:Sep 2007) draft-ietf-sip-privacy-04.txt , Appendix A (Expired: 2002) draft-rocky-sipping-calling-party-category-01.txt (Expired : 2006) =20 I've also seen implementation using parameters like isup-oli for which = I could not even find a draft. =20 Based on this I believe conveying CPC/OLI in SIP is a real requirement. Maybe for pure SIP scenario it could be done with caller-preferences, = but not in interworking scenarios. =20 From what I understand: 1. CPC in ISUP could be desired by the terminating exchange, however, = the scope of the OLI is only 1 call-leg and could be different from CPC = as it is more closely tied to the billing number. 3. CPC is ISUP only, OLI could be over MF also. =20 I don't really care what the tag-name in use is (oli/cpc)but, from = where I am looking I would say: 1. cpc-param in P-Asserted-Id corresponds to cpc in ISUP (Better = than in From header as it is a tel-uri parameter). 2. cpc-param in = History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could = correspond to OLI. =20 Is there some way of reaching consensus and moving on...rather than = have more aborted attempts in the future? =20 -Sumit =20 "The reasonable man adapts himself to the world; the unreasonable one = persists in trying to adapt the world to himself. Therefore all progress = depends on the unreasonable man." -- George Bernard Shaw From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf = Of DOLLY, MARTIN C, ATTLABS Sent: Thursday, March 27, 2008 8:04 AM To: Lee, Yiu; iptel@ietf.org; rohan@ekabal.com Subject: Re: [Iptel] draft-mahy-iptel-cpc =20 Yiu, =20 There is not a standard way to pass CPC or OLI in SIP? Also, = draft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment = needs because it blends CPC and OLI. =20 Martin =20 ________________________________ From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf = Of Lee, Yiu Sent: Thursday, March 27, 2008 3:56 AM To: iptel@ietf.org; rohan@ekabal.com Subject: [Iptel] draft-mahy-iptel-cpc Hi,=20 This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft = become WG item? If not, is there any other standard way to carry CPC or = OLI parameter in SIP?=20 Thanks,=20 Yiu=20 ------_=_NextPart_001_01C890E7.B8513B22 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc

If people agree on the need, and mixed usage is the only road-block what is preventing us from having 2 parameters…..maybe = in the next version of the draft?

 

-Sumit

 

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From:= Jesske, R [mailto:R.Jesske@telekom.de]
Sent: Friday, March 28, 2008 9:58 AM
To: mdolly@att.com; Sumit Garg; iptel@ietf.org; = sipping@ietf.org
Subject: AW: [Sipping] draft-mahy-iptel-cpc

 

Hi,

nevertheless what is the status now of cpc? Because cpc is = needed in some cases like ieps of payphone.

And we could add the OLI.

 

Thanks and Best Regards

 

Roland

 

Von:<= /b> sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] Im Auftrag = von DOLLY, MARTIN C, sbcuid
Gesendet: Freitag, 28. M=E4rz 2008 14:50
An: Sumit Garg; iptel@ietf.org; sipping@ietf.org
Betreff: Re: [Sipping] draft-mahy-iptel-cpc

Sumit,

 

What is really needed is OLI & CPC for North American = deployments. Prisons is an OLI value, not a CPC value. That is the issue with the cpc = draft it mixes up two different parameters. OLI is what type of line, where = CPC is call type ( for the most part).

 

Martin

 

From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit Garg
Sent: Friday, March 28, 2008 9:13 AM
To: iptel@ietf.org; sipping@ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc

I was surprised by the lack of = responses.

This is a real need as I believe intermediate exchanges = could need special processing for calls from Prison etc.

 

The reason I proposed using P-A-I as opposed to From = header in the draft was:

In case of anonymous calls, the From header is generally = of the form anonymous@.......

A derived tel-Uri with cpc would look like anonymous;cpc=3Dpayphone

 

This violates the tel-URI syntax. P-Asserted-Id covers = this scenario as well.

 

If there is a defined standard mechanism for this = requirement, could somebody please point me to the same?

 

-Sumit

 

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From:= = iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Sumit Garg
Sent: Thursday, March 27, 2008 9:47 AM
To: iptel@ietf.org; sipping@ietf.org
Subject: Re: [Iptel] draft-mahy-iptel-cpc

 

Over a period of time I have seen various efforts in that = direction which eventually get dropped…to list a few:

draft-schubert-sipping-saml-cpc-02.txt (Expired: jan = 2007)

draft-mahy-iptel-cpc-06.txt (Expired:Sep = 2007)

draft-ietf-sip-privacy-04.txt , Appendix A (Expired: = 2002)

draft-rocky-sipping-calling-party-category-01.txt = (Expired : 2006)

 

I’ve also seen implementation using parameters =  like isup-oli for which I could not even find a draft.

 

Based on this I believe conveying CPC/OLI in SIP is a = real requirement.

Maybe for pure SIP scenario it could be done with caller-preferences, but not in interworking = scenarios.

 

From what I understand:

1. CPC in ISUP could be desired by the terminating = exchange, however, the scope of the OLI is only 1 call-leg and could be different = from CPC as it is more closely tied to the billing = number.

3. CPC is ISUP only, OLI could be over MF = also.

 

I don’t really care what the tag-name in use is (oli/cpc)but, from where I am looking I would say:

1.     &nb= sp; cpc-param in P-Asserted-Id corresponds to cpc in ISUP (Better than in From header = as it is a tel-uri parameter).

2.     &nb= sp; cpc-param in History-Info/Diversion/P-DCS-Billing-Info/Referred-By etc. etc. could correspond to OLI.

 

Is there some way of reaching consensus and moving on…rather than have more aborted attempts in the = future?

 

-Sumit

 

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From:= iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of = DOLLY, MARTIN C, ATTLABS
Sent: Thursday, March 27, 2008 8:04 AM
To: Lee, Yiu; iptel@ietf.org; rohan@ekabal.com
Subject: Re: [Iptel] draft-mahy-iptel-cpc

 

Yiu,

 

There is not a standard way to pass CPC or OLI in SIP? Also, = d= raft-mahy-iptel-cpc-06.txt would not meet Nroth American deployment needs because it blends CPC and = OLI.

 

Martin=

 

From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Lee, Yiu
Sent: Thursday, March 27, 2008 3:56 AM
To: iptel@ietf.org; rohan@ekabal.com
Subject: [Iptel] draft-mahy-iptel-cpc

Hi, =

This draft (draft-mahy-iptel-cpc-06.txt) is expired. Will this draft become WG = item? If not, is there any other standard way to carry CPC or OLI parameter in = SIP?

Thanks,
Yiu =

------_=_NextPart_001_01C890E7.B8513B22-- --===============0318840203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============0318840203==-- From iptel-bounces@ietf.org Fri Mar 28 11:09:30 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C133C28C43B; Fri, 28 Mar 2008 11:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.793 X-Spam-Level: X-Spam-Status: No, score=-99.793 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pr9E9YCJOcf; Fri, 28 Mar 2008 11:09:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A884F28C267; Fri, 28 Mar 2008 11:09:17 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E0F3A69A0; Fri, 28 Mar 2008 11:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaZIe761sHJF; Fri, 28 Mar 2008 11:09:08 -0700 (PDT) Received: from MAILSRV01.cedarpointcom.com (mail.cedarpointcom.com [67.151.79.70]) by core3.amsl.com (Postfix) with ESMTP id 96B1F3A68FC; Fri, 28 Mar 2008 11:09:07 -0700 (PDT) Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Mar 2008 14:09:05 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 14:09:10 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkAABXNtAAAB7UjAAAviUEAAANmtwAAEbLZAAACdBYAAEWukA References: <28F05913385EAC43AF019413F674A0171246ED3F@OCCLUST04EVS1.ugd.att.com> From: "Sumit Garg" To: , X-OriginalArrivalTime: 28 Mar 2008 18:09:05.0711 (UTC) FILETIME=[CF7B33F0:01C890FE] Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0097290741==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0097290741== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C890FE.CF73A092" This is a multi-part message in MIME format. ------_=_NextPart_001_01C890FE.CF73A092 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Ian, we should avoid multiple parameters.=20 The way a lot of stuff is done in tel-uri might be useful.... =20 We would only need 1 parameter: i.) user-type=3D=20 Renamed to user-type as we do not necessarily tie it to originating side.....we might find other needs in the future. =20 For the current scenario, the number itself would help the implementation decide whether it is CPC/OLI. A global number inherently has a country code which would help decide the valid values (cpc/oli) Otherwise the phone-context could be used to decide the same. =20 For implementations which use neither..i.e. for which context is implicit...they would implicitly know whether it is cpc/oli. =20 -Sumit =20 =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Friday, March 28, 2008 12:10 PM To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc =20 Martin, =20 I saw you email with the list of values. =20 I was not proposing to remove the values but to combine them into an extended list which encompassed both OLI and CPC. ANSI does not use CPC to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI uses OLI. =20 An expanded combined single parameter may be suitable for all the required values. =20 If you look at what is proposed by 3GPP you will see that it is proposed to reduce the different CCITT operator CPC values by using 'language' in Accept-Contact. There may be options to use similar techniques to enable all the OLI values to be handled correctly. Ian Elz=20 System Manager=20 DUCI LDC UK=20 (Lucid Duck)=20 Office: + 44 24 764 35256=20 gsm: +44 7801723668=20 ian.elz@ericsson.com=20 ________________________________ ------_=_NextPart_001_01C890FE.CF73A092 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc

I agree with Ian, we should avoid multiple parameters. =

The way a lot of stuff is done in tel-uri might be useful….

 

We would only  need 1 parameter:  i.)  user-type=3D<cpc/oli-values>

         &nbs= p;      Renamed to user-type as we do not necessarily tie it to originating side…..we might find other needs in the = future.

 

For the current scenario, the number itself would help = the implementation decide whether it is CPC/OLI.

A global number inherently has a country code which would = help decide the valid values (cpc/oli)

Otherwise the phone-context could be used to decide the = same.

 

For implementations which use neither..i.e. for which = context is implicit…they would implicitly know whether  it is = cpc/oli.

 

-Sumit

 

 

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From:= Ian Elz [mailto:ian.elz@ericsson.com]
Sent: Friday, March 28, 2008 12:10 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; sipping@ietf.org
Subject: RE: [Sipping] draft-mahy-iptel-cpc

 

Martin,

 

I saw you email with the list of = values.

 

I was not proposing to remove the values but to combine them = into an extended list which encompassed both OLI and CPC. ANSI does not use = CPC to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI uses = OLI.

 

An expanded combined single parameter may be suitable for = all the required values.

 

If you look at what is proposed by 3GPP you will see that it = is proposed to reduce the different CCITT operator CPC values by using ‘language’ in Accept-Contact. There may be options to use = similar techniques to enable all the OLI values to be handled = correctly.

Ian Elz =

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668 =
ian.elz@ericsson.com

------_=_NextPart_001_01C890FE.CF73A092-- --===============0097290741== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============0097290741==-- From iptel-bounces@ietf.org Fri Mar 28 11:15:20 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E2728C43C; Fri, 28 Mar 2008 11:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.652 X-Spam-Level: X-Spam-Status: No, score=-100.652 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqtFA+P4VPEr; Fri, 28 Mar 2008 11:15:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32F528C3B3; Fri, 28 Mar 2008 11:15:08 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448B628C321; Fri, 28 Mar 2008 11:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfsvh3Eum1m8; Fri, 28 Mar 2008 11:14:58 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 5051C3A6C83; Fri, 28 Mar 2008 11:14:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1206728094!21499882!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 16653 invoked from network); 28 Mar 2008 18:14:55 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 28 Mar 2008 18:14:55 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2SIEsvR002966; Fri, 28 Mar 2008 14:14:54 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2SIEi0Z002867; Fri, 28 Mar 2008 14:14:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Mar 2008 13:14:43 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246ED45@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkAABXNtAAAB7UjAAAviUEAAANmtwAAEbLZAAACdBYAAEWukAAAAuGPA= References: <28F05913385EAC43AF019413F674A0171246ED3F@OCCLUST04EVS1.ugd.att.com> <59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> From: "DOLLY, MARTIN C, sbcuid" To: "Sumit Garg" , , Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1932854626==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============1932854626== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C890FF.991A10B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C890FF.991A10B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sumit, =20 For as long as the values are clear, this approach would be acceptable. =20 Martin ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit Garg Sent: Friday, March 28, 2008 2:09 PM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc I agree with Ian, we should avoid multiple parameters.=20 The way a lot of stuff is done in tel-uri might be useful.... =20 We would only need 1 parameter: i.) user-type=3D=20 Renamed to user-type as we do not necessarily tie it to originating side.....we might find other needs in the future. =20 For the current scenario, the number itself would help the implementation decide whether it is CPC/OLI. A global number inherently has a country code which would help decide the valid values (cpc/oli) Otherwise the phone-context could be used to decide the same. =20 For implementations which use neither..i.e. for which context is implicit...they would implicitly know whether it is cpc/oli. =20 -Sumit =20 =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Friday, March 28, 2008 12:10 PM To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc =20 Martin, =20 I saw you email with the list of values. =20 I was not proposing to remove the values but to combine them into an extended list which encompassed both OLI and CPC. ANSI does not use CPC to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI uses OLI. =20 An expanded combined single parameter may be suitable for all the required values. =20 If you look at what is proposed by 3GPP you will see that it is proposed to reduce the different CCITT operator CPC values by using 'language' in Accept-Contact. There may be options to use similar techniques to enable all the OLI values to be handled correctly. Ian Elz=20 System Manager=20 DUCI LDC UK=20 (Lucid Duck)=20 Office: + 44 24 764 35256=20 gsm: +44 7801723668=20 ian.elz@ericsson.com=20 ________________________________ ------_=_NextPart_001_01C890FF.991A10B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc
Sumit,
 
For as long as the values are clear, this = approach would be=20 acceptable.
 
Martin

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit = Garg
Sent:=20 Friday, March 28, 2008 2:09 PM
To: iptel@ietf.org;=20 sipping@ietf.org
Subject: Re: [Sipping]=20 draft-mahy-iptel-cpc

I=20 agree with Ian, we should avoid multiple parameters. =

The=20 way a lot of stuff is done in tel-uri might be = useful….

 

We=20 would only  need 1 parameter:  i.) =20 user-type=3D<cpc/oli-values>

        &= nbsp;      =20 Renamed to user-type as we do not necessarily tie it to originating = side…..we=20 might find other needs in the future.

 

For=20 the current scenario, the number itself would help the implementation = decide=20 whether it is CPC/OLI.

A=20 global number inherently has a country code which would help decide the = valid=20 values (cpc/oli)

Otherwise=20 the phone-context could be used to decide the = same.

 

For=20 implementations which use neither..i.e. for which context is = implicit…they would=20 implicitly know whether  it is cpc/oli.

 

-Sumit

 

 

"The reasonable man = adapts=20 himself to the world; the unreasonable one persists in trying to adapt = the world=20 to himself. Therefore all progress depends on the unreasonable = man."
--=20 George Bernard Shaw

From: Ian Elz=20 [mailto:ian.elz@ericsson.com]
Sent: Friday, March 28, 2008 = 12:10=20 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org;=20 sipping@ietf.org
Subject: RE: [Sipping]=20 draft-mahy-iptel-cpc

 

Martin,

 

I saw=20 you email with the list of values.

 

I was=20 not proposing to remove the values but to combine them into an extended = list=20 which encompassed both OLI and CPC. ANSI does not use CPC to any extent = while=20 ETSI/CCITT uses CPC for the same purpose as ANSI uses = OLI.

 

An=20 expanded combined single parameter may be suitable for all the required=20 values.

 

If you=20 look at what is proposed by 3GPP you will see that it is proposed to = reduce the=20 different CCITT operator CPC values by using ‘language’ in = Accept-Contact. There=20 may be options to use similar techniques to enable all the OLI values to = be=20 handled correctly.

Ian=20 Elz

System=20 Manager
DUCI LDC=20 UK
(Lucid=20 Duck)

Office:=20 + 44 24 764 35256 =
gsm: +44=20 7801723668
ian.elz@ericsson.com

------_=_NextPart_001_01C890FF.991A10B0-- --===============1932854626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============1932854626==-- From iptel-bounces@ietf.org Fri Mar 28 14:36:42 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53A263A703A; Fri, 28 Mar 2008 14:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.951 X-Spam-Level: X-Spam-Status: No, score=-100.951 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl6BYEsDnRg0; Fri, 28 Mar 2008 14:36:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022A63A6E58; Fri, 28 Mar 2008 14:36:40 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F773A6C4B; Fri, 28 Mar 2008 14:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTTV5mG2eHxf; Fri, 28 Mar 2008 14:36:36 -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 8E4BA3A69FD; Fri, 28 Mar 2008 14:36:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,572,1199682000"; d="scan'208";a="3367937" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Mar 2008 17:36:35 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2SLaZ4f029575; Fri, 28 Mar 2008 17:36:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2SLaZ3b003948; Fri, 28 Mar 2008 21:36:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 17:36:35 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Mar 2008 17:36:35 -0400 Message-ID: <47ED64FA.7020904@cisco.com> Date: Fri, 28 Mar 2008 17:36:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "DOLLY, MARTIN C, sbcuid" References: <28F05913385EAC43AF019413F674A0171246ED3F@OCCLUST04EVS1.ugd.att.com> <59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> <28F05913385EAC43AF019413F674A0171246ED45@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED45@OCCLUST04EVS1.ugd.att.com> X-OriginalArrivalTime: 28 Mar 2008 21:36:35.0058 (UTC) FILETIME=[CBDECD20:01C8911B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4264; t=1206740195; x=1207604195; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20draft-mahy-iptel-cpc |Sender:=20 |To:=20=22DOLLY,=20MARTIN=20C,=20sbcuid=22=20; bh=P362hjvl+BLoURFEjz8eHhQiSXDFXZmtcL1TYmUveAo=; b=vFYHitogMSrVKjYhGnpgsG1+lE+F90G2B5+PQyMVeMJ4Xv5AuX2AboWWja 9YaLEHBto6TMhh84RTnL5EM0agqHUp4RrruH2fAdpsLknfBbj0TbVLixSiAu 73XILLXWbV; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: iptel@ietf.org, sipping@ietf.org Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org As I recall from back when this was a topic of active discussion, there = were significant issues about the semantics of the values. I see that Rohan included semantics in the draft. But do they agree with = the ones that you are trying to interoperate with? One thing I see is that the cpc can have only one value. But the list of = values does not seem to be mutually exclusive. For instance, I would = think you could have a test call in combination with any of the others. = And you you could have a police call from a cellular phone. I suppose none of this is troubling if this is used only for calls = sourced from the PSTN, since then the problem of classifying is up to = the pstn side. But if a call originates for a sip client, there must be = clear rules for how it is classified. Also, how are the classifications authorized? It seems likely that the = originating device will not be permitted to do it, but rather that some = "trusted" middle box will have to do so. And where do you expect this to be put? In P-A-I? If that is the only = place where it makes sense, then perhaps a P-A-I header parameter would = make more sense. Paul DOLLY, MARTIN C, sbcuid wrote: > Sumit, > = > For as long as the values are clear, this approach would be acceptable. > = > Martin > = > ------------------------------------------------------------------------ > *From:* sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] *On = > Behalf Of *Sumit Garg > *Sent:* Friday, March 28, 2008 2:09 PM > *To:* iptel@ietf.org; sipping@ietf.org > *Subject:* Re: [Sipping] draft-mahy-iptel-cpc > = > I agree with Ian, we should avoid multiple parameters. > = > The way a lot of stuff is done in tel-uri might be useful=85. > = > = > = > We would only need 1 parameter: i.) user-type=3D > = > Renamed /to user-type as we do not necessarily tie it to = > originating side=85..we might find other needs in the future./ > = > = > = > For the current scenario, the number itself would help the = > implementation decide whether it is CPC/OLI. > = > A global number inherently has a country code which would help decide = > the valid values (cpc/oli) > = > Otherwise the phone-context could be used to decide the same. > = > = > = > For implementations which use neither..i.e. for which context is = > implicit=85they would implicitly know whether it is cpc/oli. > = > = > = > -Sumit > = > = > = > = > = > "The reasonable man adapts himself to the world; the unreasonable one = > persists in trying to adapt the world to himself. Therefore all progress = > depends on the unreasonable man." > -- George Bernard Shaw > = > *From:* Ian Elz [mailto:ian.elz@ericsson.com] > *Sent:* Friday, March 28, 2008 12:10 PM > *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; sipping@ietf.o= rg > *Subject:* RE: [Sipping] draft-mahy-iptel-cpc > = > = > = > Martin, > = > = > = > I saw you email with the list of values. > = > = > = > I was not proposing to remove the values but to combine them into an = > extended list which encompassed both OLI and CPC. ANSI does not use CPC = > to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI = > uses OLI. > = > = > = > An expanded combined single parameter may be suitable for all the = > required values. > = > = > = > If you look at what is proposed by 3GPP you will see that it is proposed = > to reduce the different CCITT operator CPC values by using =91language=92= in = > Accept-Contact. There may be options to use similar techniques to enable = > all the OLI values to be handled correctly. > = > /Ian Elz/ > = > /System Manager/ > /DUCI LDC UK/ > /(Lucid Duck)/ > = > /Office: + 44 24 764 35256/ > /gsm: +44 7801723668/ > /ian.elz@ericsson.com/ > = > ------------------------------------------------------------------------ > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Sat Mar 29 17:39:04 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA1728C30E; Sat, 29 Mar 2008 17:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.648 X-Spam-Level: X-Spam-Status: No, score=-100.648 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH+7rnfsGPIA; Sat, 29 Mar 2008 17:38:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCB028C152; Sat, 29 Mar 2008 17:38:46 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0FF28C117; Sat, 29 Mar 2008 17:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1fUs8eoRh4p; Sat, 29 Mar 2008 17:38:39 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id B963C3A6ACB; Sat, 29 Mar 2008 17:38:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-203.messagelabs.com!1206837511!11332903!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22782 invoked from network); 30 Mar 2008 00:38:31 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 30 Mar 2008 00:38:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2U0cZ12021202; Sat, 29 Mar 2008 20:38:35 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m2U0cTj1021179; Sat, 29 Mar 2008 20:38:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 29 Mar 2008 19:38:29 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246ED59@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <5D1A7985295922448D5550C94DE2918001D9EE30@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkAABXNtAAAB7UjAAAviUEAAANmtwAAEbLZAAACdBYAAEWukAAAAuGPAAL1JxYAAQWaPA References: <28F05913385EAC43AF019413F674A0171246ED3F@OCCLUST04EVS1.ugd.att.com><59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> <28F05913385EAC43AF019413F674A0171246ED45@OCCLUST04EVS1.ugd.att.com> <5D1A7985295922448D5550C94DE2918001D9EE30@DEEXC1U01.de.lucent.com> From: "DOLLY, MARTIN C, ATTLABS" To: "DRAGE, Keith (Keith)" , "Sumit Garg" , , Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0201899485==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0201899485== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C891FE.5FA77D20" This is a multi-part message in MIME format. ------_=_NextPart_001_01C891FE.5FA77D20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It does NOT meet the USA needs, if the ITEF says f''you, then we ...... ________________________________ From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Saturday, March 29, 2008 7:26 PM To: DOLLY, MARTIN C, ATTLABS; Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc My understanding of the cpc work in iptel is that is currently held pending the approval of the internet draft defining the approval regime for tel URI parameters. I believe the current status of this is to make the approval of tel URI parameters standards track required, although that could have altered - not in a position to look it up currently. =20 Which brings us to the next issue in that I understand that at least some of the TISPAN people want to use this as a SIP URI parameter as well as a tel URI parameter. These are two distinct sets of parameters and therefore a tel URI parameter does not automatically become a SIP URI parameter. =20 Is this so? Are there any indications which we want to be able to use with SIP URIs as well as tel URIs. =20 regards =20 Keith =20 =20 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, sbcuid Sent: Friday, March 28, 2008 6:15 PM To: Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc =09 =09 Sumit, =20 For as long as the values are clear, this approach would be acceptable. =20 Martin ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit Garg Sent: Friday, March 28, 2008 2:09 PM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc =09 =09 I agree with Ian, we should avoid multiple parameters.=20 The way a lot of stuff is done in tel-uri might be useful.... =20 We would only need 1 parameter: i.) user-type=3D=20 Renamed to user-type as we do not necessarily tie it to originating side.....we might find other needs in the future. =20 For the current scenario, the number itself would help the implementation decide whether it is CPC/OLI. A global number inherently has a country code which would help decide the valid values (cpc/oli) Otherwise the phone-context could be used to decide the same. =20 For implementations which use neither..i.e. for which context is implicit...they would implicitly know whether it is cpc/oli. =20 -Sumit =20 =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Friday, March 28, 2008 12:10 PM To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc =20 Martin, =20 I saw you email with the list of values. =20 I was not proposing to remove the values but to combine them into an extended list which encompassed both OLI and CPC. ANSI does not use CPC to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI uses OLI. =20 An expanded combined single parameter may be suitable for all the required values. =20 If you look at what is proposed by 3GPP you will see that it is proposed to reduce the different CCITT operator CPC values by using 'language' in Accept-Contact. There may be options to use similar techniques to enable all the OLI values to be handled correctly. Ian Elz=20 System Manager=20 DUCI LDC UK=20 (Lucid Duck)=20 Office: + 44 24 764 35256=20 gsm: +44 7801723668=20 ian.elz@ericsson.com=20 ________________________________ ------_=_NextPart_001_01C891FE.5FA77D20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc
It does NOT meet the USA needs, if the ITEF = says f''you,=20 then we ......

From: DRAGE, Keith (Keith)=20 [mailto:drage@alcatel-lucent.com]
Sent: Saturday, March 29, = 2008 7:26=20 PM
To: DOLLY, MARTIN C, ATTLABS; Sumit Garg; iptel@ietf.org;=20 sipping@ietf.org
Subject: RE: [Sipping]=20 draft-mahy-iptel-cpc

My understanding of the cpc work in iptel is = that is=20 currently held pending the approval of the internet draft defining the = approval=20 regime for tel URI parameters. I believe the current status of this is = to make=20 the approval of tel URI parameters standards track required, although = that could=20 have altered - not in a position to look it up = currently.
 
Which brings us to the next issue in that I = understand that=20 at least some of the TISPAN people want to use this as a SIP URI = parameter as=20 well as a tel URI parameter. These are two distinct sets of parameters = and=20 therefore a tel URI parameter does not automatically become a SIP URI=20 parameter.
 
Is this so? Are there any indications which we = want to be=20 able to use with SIP URIs as well as tel URIs.
 
regards
 
Keith
 
 

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, = sbcuid
Sent: Friday, March 28, 2008 6:15 PM
To: = Sumit=20 Garg; iptel@ietf.org; sipping@ietf.org
Subject: Re: = [Sipping]=20 draft-mahy-iptel-cpc

Sumit,
 
For as long as the values are clear, this = approach would=20 be acceptable.
 
Martin

From: sipping-bounces@ietf.org=20 [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit=20 Garg
Sent: Friday, March 28, 2008 2:09 PM
To:=20 iptel@ietf.org; sipping@ietf.org
Subject: Re: [Sipping]=20 draft-mahy-iptel-cpc

I=20 agree with Ian, we should avoid multiple parameters. =

The=20 way a lot of stuff is done in tel-uri might be = useful….

 

We=20 would only  need 1 parameter:  i.) =20 user-type=3D<cpc/oli-values>

        &= nbsp;      =20 Renamed to user-type as we do not necessarily tie it to originating = side…..we might find other needs in the = future.

 

For=20 the current scenario, the number itself would help the implementation = decide=20 whether it is CPC/OLI.

A=20 global number inherently has a country code which would help decide = the valid=20 values (cpc/oli)

Otherwise=20 the phone-context could be used to decide the = same.

 

For=20 implementations which use neither..i.e. for which context is = implicit…they=20 would implicitly know whether  it is = cpc/oli.

 

-Sumit

 

 

"The reasonable = man adapts=20 himself to the world; the unreasonable one persists in trying to adapt = the=20 world to himself. Therefore all progress depends on the unreasonable=20 man."
-- George Bernard Shaw

From: Ian Elz = [mailto:ian.elz@ericsson.com]
Sent: Friday, March 28, 2008 = 12:10=20 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org;=20 sipping@ietf.org
Subject: RE: [Sipping]=20 draft-mahy-iptel-cpc

 

Martin,

 

I saw=20 you email with the list of values.

 

I was=20 not proposing to remove the values but to combine them into an = extended list=20 which encompassed both OLI and CPC. ANSI does not use CPC to any = extent while=20 ETSI/CCITT uses CPC for the same purpose as ANSI uses=20 OLI.

 

An=20 expanded combined single parameter may be suitable for all the = required=20 values.

 

If you=20 look at what is proposed by 3GPP you will see that it is proposed to = reduce=20 the different CCITT operator CPC values by using = ‘language’ in Accept-Contact.=20 There may be options to use similar techniques to enable all the OLI = values to=20 be handled correctly.

Ian=20 Elz

System=20 Manager
DUCI=20 LDC UK
(Lucid=20 Duck)

Office:=20 + 44 24 764 35256 =
gsm:=20 +44 7801723668 =
ian.elz@ericsson.com

------_=_NextPart_001_01C891FE.5FA77D20-- --===============0201899485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============0201899485==-- From iptel-bounces@ietf.org Mon Mar 31 07:34:47 2008 Return-Path: X-Original-To: iptel-archive@megatron.ietf.org Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A27A3A6EB1; Mon, 31 Mar 2008 07:34:47 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB2C3A6EB1; Mon, 31 Mar 2008 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[AWL=1.535, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE0UQxKUw6n9; Mon, 31 Mar 2008 07:34:35 -0700 (PDT) Received: from MAILSRV01.cedarpointcom.com (mail.cedarpointcom.com [67.151.79.70]) by core3.amsl.com (Postfix) with ESMTP id 117843A6E7E; Mon, 31 Mar 2008 07:34:34 -0700 (PDT) Received: from MAIL02.cedarpointcom.com ([192.168.1.222]) by MAILSRV01.cedarpointcom.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 31 Mar 2008 10:34:31 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 10:34:27 -0400 Message-ID: <59184B4E920E854DA8ACF8E44917D49F0212FA17@MAIL02.cedarpointcom.com> In-Reply-To: <28F05913385EAC43AF019413F674A0171246ED59@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciP4AyvKryZizHZQY6C6ocMt54MXQAIlJywAAK4S+AAMbwRkAABXNtAAAB7UjAAAviUEAAANmtwAAEbLZAAACdBYAAEWukAAAAuGPAAL1JxYAAQWaPAACW43EA= References: <28F05913385EAC43AF019413F674A0171246ED3F@OCCLUST04EVS1.ugd.att.com><59184B4E920E854DA8ACF8E44917D49F0212F776@MAIL02.cedarpointcom.com> <28F05913385EAC43AF019413F674A0171246ED45@OCCLUST04EVS1.ugd.att.com> <5D1A7985295922448D5550C94DE2918001D9EE30@DEEXC1U01.de.lucent.com> <28F05913385EAC43AF019413F674A0171246ED59@OCCLUST04EVS1.ugd.att.com> From: "Sumit Garg" To: , X-OriginalArrivalTime: 31 Mar 2008 14:34:31.0234 (UTC) FILETIME=[54EF2A20:01C8933C] Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1107804769==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============1107804769== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8933C.55424F21" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8933C.55424F21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see the following areas of concern: i.) cpc/oli and overlap in values: I do not really see a major issue, I see the problem if the values were being conveyed in number format, in text format I do not see any reason why a value would be misinterpreted...a value which is not understood would automatically be inferred as default as per the policy at the receiver. I do not see a major concern in PSTN-SIP direction. In the SIP to PSTN direction, there can never be any concern for non-overlapped values...for the=20 Overlapped values..it is a matter of implementation, local predefined policy at the UAS or it making a decision based on country-code (in the =20 E.164) /phone-context. i.) Should it be part of P-A-I?? I believe what we intend to define is the URI parameter....which particular header to use is more of an implementation guideline, the CPC would generally be in P-A-I....but the implementation could pick another Header if it likes. For e.g. in PacketCable world, P-DCS-Billing-Info could also be used as it carrier=20 info about not only the charge party, but also the calling party. From Header would generally be a bad idea, but, again it depends on the trust-relationship=20 UAS has with the UAC. When OLI is being conveyed there are lots of extra options (Referred-By, Billing-Info, History-Info and even the P-A-I). SIP as opposed to ISUP provides us the freedom to carry this information derived from every leg if need be. =20 ii.) SIP URI parameter Vs. tel-URI parameter: This is the most interesting case. Do we expect the information conveyed to be useful only in interworking scenarios or could it prove to be useful in pure SIP scenarios too? If the thinking is that such information would be useful in pure SIP environments...then it would probably make sense to have it as a SIP URI parameter. The interworking case would still work without issues....as a telephony information can always be conveyed in a SIP URI, but the reverse is not true. I would prefer having 1 mapping parameter either SIP/TEL rather than whetever TISPAN is trying to do. =20 -Sumit =20 =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw =20 ________________________________ From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Saturday, March 29, 2008 7:26 PM To: DOLLY, MARTIN C, ATTLABS; Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc My understanding of the cpc work in iptel is that is currently held pending the approval of the internet draft defining the approval regime for tel URI parameters. I believe the current status of this is to make the approval of tel URI parameters standards track required, although that could have altered - not in a position to look it up currently. =20 Which brings us to the next issue in that I understand that at least some of the TISPAN people want to use this as a SIP URI parameter as well as a tel URI parameter. These are two distinct sets of parameters and therefore a tel URI parameter does not automatically become a SIP URI parameter. =20 Is this so? Are there any indications which we want to be able to use with SIP URIs as well as tel URIs. =20 regards =20 Keith =20 =20 =20 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, sbcuid Sent: Friday, March 28, 2008 6:15 PM To: Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc Sumit, =20 For as long as the values are clear, this approach would be acceptable. =20 Martin =20 ________________________________ From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit Garg Sent: Friday, March 28, 2008 2:09 PM To: iptel@ietf.org; sipping@ietf.org Subject: Re: [Sipping] draft-mahy-iptel-cpc I agree with Ian, we should avoid multiple parameters.=20 The way a lot of stuff is done in tel-uri might be useful.... =20 We would only need 1 parameter: i.) user-type=3D=20 Renamed to user-type as we do not necessarily tie it to originating side.....we might find other needs in the future. =20 For the current scenario, the number itself would help the implementation decide whether it is CPC/OLI. A global number inherently has a country code which would help decide the valid values (cpc/oli) Otherwise the phone-context could be used to decide the same. =20 For implementations which use neither..i.e. for which context is implicit...they would implicitly know whether it is cpc/oli. =20 -Sumit =20 =20 "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Friday, March 28, 2008 12:10 PM To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc =20 Martin, =20 I saw you email with the list of values. =20 I was not proposing to remove the values but to combine them into an extended list which encompassed both OLI and CPC. ANSI does not use CPC to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI uses OLI. =20 An expanded combined single parameter may be suitable for all the required values. =20 If you look at what is proposed by 3GPP you will see that it is proposed to reduce the different CCITT operator CPC values by using 'language' in Accept-Contact. There may be options to use similar techniques to enable all the OLI values to be handled correctly. Ian Elz=20 System Manager=20 DUCI LDC UK=20 (Lucid Duck)=20 Office: + 44 24 764 35256=20 gsm: +44 7801723668=20 ian.elz@ericsson.com=20 ________________________________ ------_=_NextPart_001_01C8933C.55424F21 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-mahy-iptel-cpc

I see the following areas of = concern:

i.)           = ;       cpc/oli and overlap in values:

    = ;    I do not really see a major issue, I see the problem if the = values were being conveyed in number format, in text format I do not see any = reason

   =      why a value would be misinterpreted…a value which is not understood = would automatically be inferred as default as per the policy at the = receiver.

    = ;   I do not see a major concern in PSTN-SIP direction. In the SIP to PSTN direction, there can never be any concern for non-overlapped = values…for the

    = ;  Overlapped values..it is a matter of implementation, local predefined = policy at the UAS or it making a decision based on  country-code (in the =   

    = ;  E.164) /phone-context.

i.)           = ;       Should it be part of P-A-I??

     =            I believe what we intend to define is the URI parameter….which = particular header to use is more of an implementation guideline, the CPC would = generally

         &nbs= p;      be in P-A-I….but the implementation could pick another Header if = it likes. For e.g. in PacketCable world, P-DCS-Billing-Info could also be = used as it carrier

         &nbs= p;      info about not only the charge party, but also the calling party. =  From Header would generally be a bad idea, but, again it depends on the = trust-relationship

         &nbs= p;     UAS has with the UAC.  When OLI is being conveyed there are lots of = extra options (Referred-By, Billing-Info, History-Info and even the P-A-I). = SIP as opposed to ISUP provides us the freedom to carry this information = derived from every leg if need be.

 

ii.)           = ;      SIP URI parameter Vs. tel-URI = parameter:

 This is the most interesting case. Do we expect the information conveyed to be useful = only in interworking scenarios or could it prove to be useful in pure SIP = scenarios too?   If  the thinking is that such information would be = useful in pure SIP environments…then it would probably make sense to have it = as a SIP URI parameter. The interworking case would still work without = issues….as a telephony information can always be conveyed in a SIP URI, but the = reverse is not true.

I would prefer having = 1 mapping parameter either SIP/TEL rather than whetever TISPAN is trying = to do.

 

-Sumit

 

         &nbs= p;          

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

 

From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
Sent: Saturday, March 29, 2008 7:26 PM
To: DOLLY, MARTIN C, ATTLABS; Sumit Garg; iptel@ietf.org; sipping@ietf.org
Subject: RE: [Sipping] draft-mahy-iptel-cpc

My understanding of the cpc work in iptel is that is = currently held pending the approval of the internet draft defining the approval regime = for tel URI parameters. I believe the current status of this is to make the = approval of tel URI parameters standards track required, although that could have = altered - not in a position to look it up currently.

 

Which brings us to the next issue in that I understand that = at least some of the TISPAN people want to use this as a SIP URI parameter = as well as a tel URI parameter. These are two distinct sets of parameters and = therefore a tel URI parameter does not automatically become a SIP URI = parameter.

 

Is this so? Are there any indications which we want to be = able to use with SIP URIs as well as tel URIs.

 

regards

 

Keith

 

 

 

From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, = sbcuid
Sent: Friday, March 28, 2008 6:15 PM
To: Sumit Garg; iptel@ietf.org; sipping@ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc

Sumit,

 

For as long as the values are clear, this approach would be acceptable.

 

Martin

 

From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Sumit Garg
Sent: Friday, March 28, 2008 2:09 PM
To: iptel@ietf.org; sipping@ietf.org
Subject: Re: [Sipping] draft-mahy-iptel-cpc

I agree with Ian, we should avoid multiple parameters. =

The way a lot of stuff is done in tel-uri might be useful….

 

We would only  need 1 parameter:  i.)  user-type=3D<cpc/oli-values>

         &nbs= p;      Renamed to user-type as we do not necessarily tie it to originating side…..we might find other needs in the = future.

 

For the current scenario, the number itself would help = the implementation decide whether it is CPC/OLI.

A global number inherently has a country code which would = help decide the valid values (cpc/oli)

Otherwise the phone-context could be used to decide the = same.

 

For implementations which use neither..i.e. for which = context is implicit…they would implicitly know whether  it is = cpc/oli.

 

-Sumit

 

 

"The reasonable = man adapts himself to the world; the unreasonable one persists in trying to adapt = the world to himself. Therefore all progress depends on the unreasonable = man."
-- George Bernard Shaw

From:= Ian Elz [mailto:ian.elz@ericsson.com]
Sent: Friday, March 28, 2008 12:10 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; sipping@ietf.org
Subject: RE: [Sipping] draft-mahy-iptel-cpc

 

Martin,

 

I saw you email with the list of = values.

 

I was not proposing to remove the values but to combine them = into an extended list which encompassed both OLI and CPC. ANSI does not use = CPC to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI uses = OLI.

 

An expanded combined single parameter may be suitable for = all the required values.

 

If you look at what is proposed by 3GPP you will see that it = is proposed to reduce the different CCITT operator CPC values by using ‘language’ in Accept-Contact. There may be options to use = similar techniques to enable all the OLI values to be handled = correctly.

Ian Elz =

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668 =
ian.elz@ericsson.com

------_=_NextPart_001_01C8933C.55424F21-- --===============1107804769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel --===============1107804769==-- From WileymadelinePacheco@fedex.com Mon Mar 31 09:01:51 2008 Return-Path: X-Original-To: ietfarch-iptel-archive@core3.amsl.com Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9563A6C06; Mon, 31 Mar 2008 09:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -73.825 X-Spam-Level: X-Spam-Status: No, score=-73.825 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_PAST_12_24=0.992, FH_RELAY_NODNS=1.451, FM_DOESNT_SAY_STOCK=10.357, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_MLH_Stock7=1.66, SARE_RMML_Stock25=0.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 ltN9H8JrkI+u; Mon, 31 Mar 2008 09:01:47 -0700 (PDT) Received: from contabiliad2.rwplastics.local (unknown [189.139.41.54]) by core3.amsl.com (Postfix) with SMTP id 4127E3A6814; Mon, 31 Mar 2008 09:01:47 -0700 (PDT) Received: from 10208114392322316.12658150826083451.13981150111925692.17075848032280051 (HELO localhost.localdomain) (14019200960010552.10767360325118710.13653974494073767.14129074996539428) by 16798638027074627.11028340506394464.15314324498827284.16528564665169507 with SMTP; Mon, 31 Mar 2008 10:01:32 +0600 Date: Mon, 31 Mar 2008 10:01:32 +0600 Message-Id: <7IX823EJXVWDA291@fedex.com> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 237778 X-Header-Versions: Hewlett-Packard.1t9bn9nd3.fk@us.newsgram.hp.com X-FID: 32E37DBC-6034-30AF-B3E3-42CDEA69DCB5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: From: "Rickie Rojas" Subject: Aggressive Investors Alert Introducing the new tech giant in the making DNC MultiMedia Corp Symbol: DCNM This is a hugely undervalued Gem with high profile clients such as Microsoft, Samsung, LG, and Napster the huge volume and price spike today on the news release is a good indicator of short and long term movement. See the company's outstanding pr and pull the trigger on DCNM From iptel-bounces@ietf.org Mon Mar 31 09:50:14 2008 Return-Path: X-Original-To: iptel-archive@megatron.ietf.org Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72E2C28C27D; Mon, 31 Mar 2008 09:50:14 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4BC628C242; Mon, 31 Mar 2008 09:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.88 X-Spam-Level: X-Spam-Status: No, score=-3.88 tagged_above=-999 required=5 tests=[AWL=2.719, 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 i8tpXMX3iVGW; Mon, 31 Mar 2008 09:50:10 -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 7674F28C224; Mon, 31 Mar 2008 09:50:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,583,1199682000"; d="scan'208";a="3520698" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2008 12:50:05 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2VGo5aT030920; Mon, 31 Mar 2008 12:50:05 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2VGo5vV029599; Mon, 31 Mar 2008 16:50:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:50:05 -0400 Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:50:04 -0400 Message-ID: <47F11654.6050607@cisco.com> Date: Mon, 31 Mar 2008 12:50:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ian Elz References: In-Reply-To: X-OriginalArrivalTime: 31 Mar 2008 16:50:04.0692 (UTC) FILETIME=[44DA5D40:01C8934F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6706; t=1206982205; x=1207846205; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sipping]=20draft-mahy-iptel-cpc |Sender:=20 |To:=20Ian=20Elz=20; bh=EjE20JcT3cfwn2y7YA34K51STOa+/yh7kPhXZB4rzlk=; b=KOaqYemykfVt0Y6cHDJOKQNT4n6mTwJFNHoYPiQC4LR1QJOf5L7zn4uAZp HQGdgD7U+t/hzoK0wJpLyP7SDGAIUi3baUmBs/q4SdNTVFEBrgNzNdtNYFum kn8klJQ93Y; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: iptel@ietf.org, "DOLLY, MARTIN C, sbcuid" , sipping@ietf.org Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Ian Elz wrote: > Paul, > > You are now stretching the requirements for CPC/OLI beyond what is now > supported in ISUP. Is CPC just for ISUP? > In current ISUP it would be possible to have as you correctly describe a > police cell phone but only a single value is included. > > If you wish to allow multiple values then we raise an interworking > problem of which value is used when interworking with ISUP. We may need > to define one value as primary and others as secondary to allow correct > interworking. My issue is just to clarify the semantics. The draft as written specifies as mutually exclusive alternatives a number of things that on the surface don't appear to be mutually exclusive. Nor is it especially clear about how these properties are to be determined. I assume that somehow or other the meaning of these is specified in the PSTN. But that isn't of much help to a SIP UA that is trying to implement this. If the semantics can be spelled out in a way that makes it clear how to deal with the overlapping cases then so be it. (Does "police" trump "cellular" or visa versa? Or is this only to be used in networks where there can never be cellular police phones?) Paul > Ian Elz > > System Manager > DUCI LDC UK > (Lucid Duck) > > Office: + 44 24 764 35256 > gsm: +44 7801723668 > ian.elz@ericsson.com > > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 28 March 2008 21:37 > To: DOLLY, MARTIN C, sbcuid > Cc: iptel@ietf.org; sipping@ietf.org > Subject: Re: [Sipping] draft-mahy-iptel-cpc > > As I recall from back when this was a topic of active discussion, there > were significant issues about the semantics of the values. > > I see that Rohan included semantics in the draft. But do they agree with > > the ones that you are trying to interoperate with? > > One thing I see is that the cpc can have only one value. But the list of > > values does not seem to be mutually exclusive. For instance, I would > think you could have a test call in combination with any of the others. > And you you could have a police call from a cellular phone. > > I suppose none of this is troubling if this is used only for calls > sourced from the PSTN, since then the problem of classifying is up to > the pstn side. But if a call originates for a sip client, there must be > clear rules for how it is classified. > > Also, how are the classifications authorized? It seems likely that the > originating device will not be permitted to do it, but rather that some > "trusted" middle box will have to do so. > > And where do you expect this to be put? In P-A-I? If that is the only > place where it makes sense, then perhaps a P-A-I header parameter would > make more sense. > > Paul > > DOLLY, MARTIN C, sbcuid wrote: >> Sumit, >> >> For as long as the values are clear, this approach would be > acceptable. >> >> Martin >> >> > ------------------------------------------------------------------------ >> *From:* sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] *On > >> Behalf Of *Sumit Garg >> *Sent:* Friday, March 28, 2008 2:09 PM >> *To:* iptel@ietf.org; sipping@ietf.org >> *Subject:* Re: [Sipping] draft-mahy-iptel-cpc >> >> I agree with Ian, we should avoid multiple parameters. >> >> The way a lot of stuff is done in tel-uri might be useful.... >> >> >> >> We would only need 1 parameter: i.) user-type= >> >> Renamed /to user-type as we do not necessarily tie it > to >> originating side.....we might find other needs in the future./ >> >> >> >> For the current scenario, the number itself would help the >> implementation decide whether it is CPC/OLI. >> >> A global number inherently has a country code which would help decide >> the valid values (cpc/oli) >> >> Otherwise the phone-context could be used to decide the same. >> >> >> >> For implementations which use neither..i.e. for which context is >> implicit...they would implicitly know whether it is cpc/oli. >> >> >> >> -Sumit >> >> >> >> >> >> "The reasonable man adapts himself to the world; the unreasonable one >> persists in trying to adapt the world to himself. Therefore all > progress >> depends on the unreasonable man." >> -- George Bernard Shaw >> >> *From:* Ian Elz [mailto:ian.elz@ericsson.com] >> *Sent:* Friday, March 28, 2008 12:10 PM >> *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org; > sipping@ietf.org >> *Subject:* RE: [Sipping] draft-mahy-iptel-cpc >> >> >> >> Martin, >> >> >> >> I saw you email with the list of values. >> >> >> >> I was not proposing to remove the values but to combine them into an >> extended list which encompassed both OLI and CPC. ANSI does not use > CPC >> to any extent while ETSI/CCITT uses CPC for the same purpose as ANSI >> uses OLI. >> >> >> >> An expanded combined single parameter may be suitable for all the >> required values. >> >> >> >> If you look at what is proposed by 3GPP you will see that it is > proposed >> to reduce the different CCITT operator CPC values by using 'language' > in >> Accept-Contact. There may be options to use similar techniques to > enable >> all the OLI values to be handled correctly. >> >> /Ian Elz/ >> >> /System Manager/ >> /DUCI LDC UK/ >> /(Lucid Duck)/ >> >> /Office: + 44 24 764 35256/ >> /gsm: +44 7801723668/ >> /ian.elz@ericsson.com/ >> >> > ------------------------------------------------------------------------ >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Apr 1 05:46:58 2008 Return-Path: X-Original-To: iptel-archive@megatron.ietf.org Delivered-To: ietfarch-iptel-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3C028C76B; Tue, 1 Apr 2008 05:46:58 -0700 (PDT) X-Original-To: iptel@core3.amsl.com Delivered-To: iptel@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA4828C747; Tue, 1 Apr 2008 05:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.806 X-Spam-Level: X-Spam-Status: No, score=-103.806 tagged_above=-999 required=5 tests=[AWL=2.793, 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 KpalS1OcI5ct; Tue, 1 Apr 2008 05:46:56 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 9DC1028D0AF; Tue, 1 Apr 2008 05:16:27 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1207052181!20990343!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 9095 invoked from network); 1 Apr 2008 12:16:22 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 1 Apr 2008 12:16:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m31CGLWH015175; Tue, 1 Apr 2008 08:16:21 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m31CGG3s015146; Tue, 1 Apr 2008 08:16:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 07:16:15 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246ED8B@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sipping] draft-mahy-iptel-cpc Thread-Index: AciTT0huJkK+FBR7RpWeyPG2fMdD0gAhlBHQAAUtSrA= References: <47F11654.6050607@cisco.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Ian Elz" , , Subject: Re: [Iptel] [Sipping] draft-mahy-iptel-cpc X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org Ian, CPC: Information sent in the forward direction indicating the category of the calling party and, in case of semiautomatic calls, the service language to be spoken by the incoming, delay and assistance operators. The format of the calling party's category is shown below. OLI: Information sent in the forward direction indicating toll class of service. Identification of the originating line. Martin -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Tuesday, April 01, 2008 4:58 AM To: Paul Kyzivat Cc: iptel@ietf.org; DOLLY, MARTIN C, ATTLABS; sipping@ietf.org Subject: RE: [Sipping] draft-mahy-iptel-cpc Paul, My comments are made based upon the content of the latest draft (06). The introduction begins: "SS7 ISUP [4] defines a Calling Party's Category (CPC) parameter that characterizes the station used to originate a call and carries other important state that can describe the originating party. When telephone numbers are contained in URIs, such as the tel URI [2], it may be desirable to communicate any CPC associated with that telephone number or, in the context of a call, the party calling from it." Based upon this the current requirement appears to be to support the ISUP CPC/OLI. If the requirement is greater than this then that is a discussion that we should have before the draft is finalized. The issue with mutual exclusivity exists in the current ISUP implementations. If that limitation is to be overcome then that requirement also needs to be discussed. If we are to move from mutual exclusivity of values then we need to ensure that interworking back to ISUP is supported. The resolution of the overlapping cases as you have indicated may have to be at the discretion of the network operator. Ian Elz _______________________________________________ Iptel mailing list Iptel@ietf.org https://www.ietf.org/mailman/listinfo/iptel