From mailman-bounces@ietf.org Mon Nov 1 06:46:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20104 for ; Mon, 1 Nov 2004 06:46:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COasd-000563-If for iptel-web-archive@ietf.org; Mon, 01 Nov 2004 07:01:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZRj-0001s1-K5 for iptel-web-archive@ietf.org; Mon, 01 Nov 2004 05:29:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: iptel-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:11:10 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for iptel-web-archive@ietf.org: List Password // URL ---- -------- iptel@ietf.org aroxgu https://www1.ietf.org/mailman/options/iptel/iptel-web-archive%40ietf.org From iptel-bounces@ietf.org Mon Nov 1 12:53:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09065 for ; Mon, 1 Nov 2004 12:53:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgbg-0005gi-87 for iptel-web-archive@ietf.org; Mon, 01 Nov 2004 13:08:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COg2z-0007er-It; Mon, 01 Nov 2004 12:32:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfht-0002bX-6z; Mon, 01 Nov 2004 12:11:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04828; Mon, 1 Nov 2004 12:10:59 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COfwp-0004aX-89; Mon, 01 Nov 2004 12:26:27 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iA1HAIi11453; Mon, 1 Nov 2004 09:10:18 -0800 (PST) Message-Id: <200411011710.iA1HAIi11453@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 01 Nov 2004 09:10:18 -0800 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: iptel@ietf.org, rfc-editor@rfc-editor.org Subject: [Iptel] RFC 3880 on Call Processing Language (CPL): A Language for User Control of Internet Telephony Services X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3880 Title: Call Processing Language (CPL): A Language for User Control of Internet Telephony Services Author(s): J. Lennox, X. Wu, H. Schulzrinne Status: Standards Track Date: October 2004 Mailbox: lennox@cs.columbia.edu, xiaotaow@cs.columbia.edu, schulzrinne@cs.columbia.edu Pages: 74 Characters: 154991 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-iptel-cpl-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3880.txt This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony Working Goup of the IETF. This is now a Proposed Standard Protocol. 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. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <041101090850.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3880 --OtherAccess Content-Type: Message/External-body; name="rfc3880.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <041101090850.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --NextPart-- From iptel-bounces@ietf.org Tue Nov 2 10:49:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02939 for ; Tue, 2 Nov 2004 10:49:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP19Q-0004nu-E1 for iptel-web-archive@ietf.org; Tue, 02 Nov 2004 11:04:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0i7-00085E-5q; Tue, 02 Nov 2004 10:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0VZ-0002OQ-TT for iptel@megatron.ietf.org; Tue, 02 Nov 2004 10:23:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00133 for ; Tue, 2 Nov 2004 10:23:40 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0kh-00042q-Ax for iptel@ietf.org; Tue, 02 Nov 2004 10:39:20 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 02 Nov 2004 07:35:38 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iA2FN7JZ000895 for ; Tue, 2 Nov 2004 07:23:07 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-142.cisco.com [10.21.96.142]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFL91503; Tue, 2 Nov 2004 07:23:06 -0800 (PST) Message-ID: <4187A659.1060003@cisco.com> Date: Tue, 02 Nov 2004 10:23:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [Iptel] Agenda for iptel meeting X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Folks, Here is our agenda for the iptel meeting in D.C. I believe our time slot has changed due to the conflict with simple, though this does not yet appear to be reflected in the online schedule. Please stay posted regarding the specific time. Are there any additional items folks would like to see covered? IP Telephony WG (IPTEL) TUESDAY, November 9, 2004, 1300-1400 ==================================== CHAIRS: Jonathan Rosenberg Cullen Jennings AGENDA: 5 min Agenda Bashing Chairs Bluesheet, Scribe 20 min Enum Indicator Richard Stastny draft-stastny-iptel-tel-enumdi-00.txt DNS URL 30 min Plan for concluding work Chairs Et.Al. draft-ietf-iptel-tgrep-04.txt draft-ietf-iptel-tel-np-02.txt draft-ietf-iptel-trunk-group-02.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 2 11:42:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08325 for ; Tue, 2 Nov 2004 11:42:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1yq-0006HB-4w for iptel-web-archive@ietf.org; Tue, 02 Nov 2004 11:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1IF-0008Rf-Oj; Tue, 02 Nov 2004 11:13:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP135-0000zR-0Z for iptel@megatron.ietf.org; Tue, 02 Nov 2004 10:58:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03647 for ; Tue, 2 Nov 2004 10:58:17 -0500 (EST) From: hisham.khartabil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1IB-00050N-Ks for iptel@ietf.org; Tue, 02 Nov 2004 11:13:58 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2FvDe07267; Tue, 2 Nov 2004 17:57:13 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 17:57:18 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA2FvIKo021398; Tue, 2 Nov 2004 17:57:18 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 001dUDQL; Tue, 02 Nov 2004 17:57:16 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2FunS20844; Tue, 2 Nov 2004 17:56:49 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 17:56:49 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 17:56:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Agenda for iptel meeting Date: Tue, 2 Nov 2004 17:56:48 +0200 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8C05@esebe056.ntc.nokia.com> Thread-Topic: [Iptel] Agenda for iptel meeting Thread-Index: AcTA8+UUkohjnip7RHy4laOBFRYnPAAAJjoA To: , X-OriginalArrivalTime: 02 Nov 2004 15:56:48.0913 (UTC) FILETIME=[8FBA7010:01C4C0F4] X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Whatever happened to = http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt Should we take this to sipping? /Hisham > -----Original Message----- > From: iptel-bounces@ietf.org=20 > [mailto:iptel-bounces@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 02.November.2004 17:23 > To: list iptel > Subject: [Iptel] Agenda for iptel meeting >=20 >=20 > Folks, >=20 > Here is our agenda for the iptel meeting in D.C. I believe=20 > our time slot=20 > has changed due to the conflict with simple, though this does not yet=20 > appear to be reflected in the online schedule. Please stay posted=20 > regarding the specific time. >=20 > Are there any additional items folks would like to see covered? >=20 > IP Telephony WG (IPTEL) >=20 > TUESDAY, November 9, 2004, 1300-1400 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > CHAIRS: Jonathan Rosenberg > Cullen Jennings >=20 > AGENDA: >=20 > 5 min Agenda Bashing Chairs > Bluesheet, Scribe >=20 > 20 min Enum Indicator Richard Stastny > draft-stastny-iptel-tel-enumdi-00.txt > DNS URL >=20 > 30 min Plan for concluding work Chairs Et.Al. > draft-ietf-iptel-tgrep-04.txt > draft-ietf-iptel-tel-np-02.txt > draft-ietf-iptel-trunk-group-02.txt >=20 >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 2 12:19:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13873 for ; Tue, 2 Nov 2004 12:19:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2YE-0007Vi-IX for iptel-web-archive@ietf.org; Tue, 02 Nov 2004 12:34:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1nd-0006Ps-2r; Tue, 02 Nov 2004 11:46:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP1hI-0002U3-1Z for iptel@megatron.ietf.org; Tue, 02 Nov 2004 11:39:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08029 for ; Tue, 2 Nov 2004 11:39:49 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP1wQ-00069D-2U for iptel@ietf.org; Tue, 02 Nov 2004 11:55:31 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 02 Nov 2004 08:39:36 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iA2GdHJZ022930; Tue, 2 Nov 2004 08:39:17 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-142.cisco.com [10.21.96.142]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFL95837; Tue, 2 Nov 2004 08:39:16 -0800 (PST) Message-ID: <4187B833.3060409@cisco.com> Date: Tue, 02 Nov 2004 11:39:15 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com Subject: Re: [Iptel] Agenda for iptel meeting References: <5816828233DEFA41807A6CFDFDF2343C3A8C05@esebe056.ntc.nokia.com> In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8C05@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit This is a good question. I pinged Brian on this, and his view was that the plan was to submit to iesg directly; i.e., it didn't require becoming an iptel item. I am fine either way; the draft is sufficiently short that it's not clear it really matters. In either case, if you have comments, please do make them. It is appropriate for those comments to be made to the iptel list. Thanks, Jonathan R. hisham.khartabil@nokia.com wrote: > Whatever happened to http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt > > Should we take this to sipping? > > /Hisham > > >>-----Original Message----- >>From: iptel-bounces@ietf.org >>[mailto:iptel-bounces@ietf.org]On Behalf Of >>ext Jonathan Rosenberg >>Sent: 02.November.2004 17:23 >>To: list iptel >>Subject: [Iptel] Agenda for iptel meeting >> >> >>Folks, >> >>Here is our agenda for the iptel meeting in D.C. I believe >>our time slot >>has changed due to the conflict with simple, though this does not yet >>appear to be reflected in the online schedule. Please stay posted >>regarding the specific time. >> >>Are there any additional items folks would like to see covered? >> >>IP Telephony WG (IPTEL) >> >>TUESDAY, November 9, 2004, 1300-1400 >>==================================== >> >>CHAIRS: Jonathan Rosenberg >> Cullen Jennings >> >>AGENDA: >> >> 5 min Agenda Bashing Chairs >> Bluesheet, Scribe >> >>20 min Enum Indicator Richard Stastny >> draft-stastny-iptel-tel-enumdi-00.txt >> DNS URL >> >>30 min Plan for concluding work Chairs Et.Al. >> draft-ietf-iptel-tgrep-04.txt >> draft-ietf-iptel-tel-np-02.txt >> draft-ietf-iptel-trunk-group-02.txt >> >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Director, Service Provider VoIP Architecture Parsippany, NJ >>07054-2711 >>Cisco Systems >>jdrosen@cisco.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.cisco.com >> >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Nov 4 11:20:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06044 for ; Thu, 4 Nov 2004 11:20:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkbE-0008F4-7s for iptel-web-archive@ietf.org; Thu, 04 Nov 2004 11:36:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPkId-0000y2-SH; Thu, 04 Nov 2004 11:17:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPk9B-00072I-0X for iptel@megatron.ietf.org; Thu, 04 Nov 2004 11:07:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04889 for ; Thu, 4 Nov 2004 11:07:35 -0500 (EST) From: hisham.khartabil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPkOi-0007wA-Dk for iptel@ietf.org; Thu, 04 Nov 2004 11:23:41 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4G7LE17256; Thu, 4 Nov 2004 18:07:21 +0200 (EET) X-Scanned: Thu, 4 Nov 2004 18:07:32 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA4G7WWM024655; Thu, 4 Nov 2004 18:07:32 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00pTAWeA; Thu, 04 Nov 2004 18:07:31 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4G6oS07796; Thu, 4 Nov 2004 18:06:50 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 18:06:50 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 18:06:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Agenda for iptel meeting Date: Thu, 4 Nov 2004 18:06:49 +0200 Message-ID: <5816828233DEFA41807A6CFDFDF2343C3A8C1C@esebe056.ntc.nokia.com> Thread-Topic: [Iptel] Agenda for iptel meeting Thread-Index: AcTA+qaEFvUTqjf8QIudbP5R0SspdQBjUuDA To: X-OriginalArrivalTime: 04 Nov 2004 16:06:50.0762 (UTC) FILETIME=[4B48CEA0:01C4C288] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Myself, Brian and Richard Stastny have been discussing some issues in = the draft but I haven't seen an update reflecting the discussion. When = do we expect to see that version? Thanks, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: 02.November.2004 18:39 > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > Cc: iptel@ietf.org > Subject: Re: [Iptel] Agenda for iptel meeting >=20 >=20 > This is a good question. I pinged Brian on this, and his view=20 > was that=20 > the plan was to submit to iesg directly; i.e., it didn't require=20 > becoming an iptel item. I am fine either way; the draft is=20 > sufficiently=20 > short that it's not clear it really matters. In either case,=20 > if you have=20 > comments, please do make them. It is appropriate for those=20 > comments to=20 > be made to the iptel list. >=20 > Thanks, > Jonathan R. >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Whatever happened to=20 > http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstri > ng-00.txt > >=20 > > Should we take this to sipping? > >=20 > > /Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: iptel-bounces@ietf.org=20 > >>[mailto:iptel-bounces@ietf.org]On Behalf Of > >>ext Jonathan Rosenberg > >>Sent: 02.November.2004 17:23 > >>To: list iptel > >>Subject: [Iptel] Agenda for iptel meeting > >> > >> > >>Folks, > >> > >>Here is our agenda for the iptel meeting in D.C. I believe=20 > >>our time slot=20 > >>has changed due to the conflict with simple, though this=20 > does not yet=20 > >>appear to be reflected in the online schedule. Please stay posted=20 > >>regarding the specific time. > >> > >>Are there any additional items folks would like to see covered? > >> > >>IP Telephony WG (IPTEL) > >> > >>TUESDAY, November 9, 2004, 1300-1400 > = >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >>CHAIRS: Jonathan Rosenberg > >> Cullen Jennings > >> > >>AGENDA: > >> > >> 5 min Agenda Bashing Chairs > >> Bluesheet, Scribe > >> > >>20 min Enum Indicator Richard Stastny > >> draft-stastny-iptel-tel-enumdi-00.txt > >> DNS URL > >> > >>30 min Plan for concluding work Chairs Et.Al. > >> draft-ietf-iptel-tgrep-04.txt > >> draft-ietf-iptel-tel-np-02.txt > >> draft-ietf-iptel-trunk-group-02.txt > >> > >> > >>Thanks, > >>Jonathan R. > >>--=20 > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Director, Service Provider VoIP Architecture Parsippany, NJ=20 > >>07054-2711 > >>Cisco Systems > >>jdrosen@cisco.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.cisco.com > >> > >> > >>_______________________________________________ > >>Iptel mailing list > >>Iptel@ietf.org > >>https://www1.ietf.org/mailman/listinfo/iptel > >> > >=20 > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Nov 4 18:07:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20176 for ; Thu, 4 Nov 2004 18:07:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqxH-0002EF-MN for iptel-web-archive@ietf.org; Thu, 04 Nov 2004 18:23:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqdJ-0005XI-7D; Thu, 04 Nov 2004 18:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqVw-0001hS-11 for iptel@megatron.ietf.org; Thu, 04 Nov 2004 17:55:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18692 for ; Thu, 4 Nov 2004 17:55:29 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqlY-0001v6-1C for iptel@ietf.org; Thu, 04 Nov 2004 18:11:40 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2004 15:05:43 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA4Msvcp003463; Thu, 4 Nov 2004 14:54:58 -0800 (PST) Received: from [10.32.131.248] ([10.32.131.248]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATT00192; Thu, 4 Nov 2004 14:54:57 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Nov 2004 14:54:56 -0800 From: Cullen Jennings To: Jonathan Rosenberg , Manjunath S Bangalore , , Hussein F Salama , Dhaval N Shah , "iptel@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings Subject: [Iptel] tgrep 04 comments X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7bit I like this document and have read it so many times that I have lost any objective ability to catch mistakes in it. Anyways, here are some NITS that come to mind .... (PS. If you want me to help convert this to XML2RFC to deal with a bunch of this, I would be happy to help after IETF) Needs a table of contents as it is over 15 pages. Expand first use of TRIP in abstract In the Security Section might want to include some of the evil things that can happen if you don't follow security recommendations in 3219 like DOS of all phone calls on your network, misrouting of calls, stealing calls meant for carrier A to carrier B, acceleration of heat death of universe, and so on. Move to new boiler plate. Update Jonathans contact info. Warning in the introduction that you have to read 3219 for this to make any sense. I don't see the numbers for the new address families. Section 3.7.1 had duplicate text abut how CarrierIdCode is formed. Could we put this in just one place to reduce the chance of having it conflict. Split references into Normative and Informative. In the IANA section, put something along the lines of .... Trash the Changes sections. Update the table at http://www.iana.org/assignments/trip-parameters to have TRIP Attributes Code Attribute Reference ------- -------------------------- --------- 14 AvailableCircuits [RFC-AAAA] TRIP Address Families Code Address Family Reference ----------- --------------------------- --------- 4 TrunkGroup [RFC-AAAA] [Note to RFC Editor - replace RFC-AAAA with this RFC number] Some spelling typos (or perhaps these are OK and I just don't know the various ways to spell the work but, for what they are worth) 57c57 < turn can propogate that routing information within and between --- > turn can propagate that routing information within and between 59c59 < of similarites with the TRIP Protocol. It has similar procedures and --- > of similarities with the TRIP Protocol. It has similar procedures and 158c158 < and/or propogated by the TRIP Location Server. --- > and/or propagated by the TRIP Location Server. 171c171 < UPDATE message to propogate the routes supported. It uses --- > UPDATE message to propagate the routes supported. It uses 202c202 < speaker sends the reachibility informaton in the UPDATE messages. The --- > speaker sends the reachibility information in the UPDATE messages. The 252c252 < MAY be propogated beyond the LS that receives it. --- > MAY be propagated beyond the LS that receives it. 687c687 < When the scope of a CarrierIdCode is known to be unique apriori, the --- > When the scope of a CarrierIdCode is known to be unique a priori, the 844c844 < When the scope of a CarrierIdCode is known to be unique apriori, the --- > When the scope of a CarrierIdCode is known to be unique a priori, the 983c983 < MUST NOT send UPDATEs of more than one of the following catagories --- > MUST NOT send UPDATEs of more than one of the following categories 1076c1076 < | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW | --- > | | (I-TRIP/ | | |t| |d| | Management |-++-+-------| GW | 1130c1130 < | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW | --- > | | (I-TRIP/ | | |t| |d| | Management |-++-+-------| GW | 1181c1181 < refered to as Consolidation. In the above example, it is possible --- > referred to as Consolidation. In the above example, it is possible 1328c1328 < to accomodate representation of Country codes in association with --- > to accommodate representation of Country codes in association with idnits says ... idnits 1.34 (28 Jul 2004) /Users/fluffy/id/draft-ietf-iptel-tgrep-04.txt: The document seems to lack separate sections for Informative/Normative References * The document claims conformance with section 10 of RFC 2026, but uses some RFC 3667/3668 boilerplate. As RFC 3667/3668 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3667/3668 boilerplate. Looks like you're using RFC 2026 boilerplate. Better change to RFC 3667/3668. The document seems to lack an 2026 Section 10.4(C) Copyright Notice -- however, there's a paragraph with a matching beginning. Boilerplate error? The document seems to lack an RFC 2026 Section 10.4(C) Permission Grants Notice The document seems to lack an RFC 2026 Section 10.4(C) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? The document is more than 15 pages and seems to lack a Table of Contents There are 39 instances of too long lines in the document, -- the longest one being 22 characters in excess of 72. Warnings: There are 1 instances of lines with hyphenated line breaks in the document. Line 325 has weird spacing: '...s to be deter...' Line 388 has weird spacing: '...refixes that...' Line 393 has weird spacing: '...ges may be re...' Line 466 has weird spacing: '...nkgroup for t...' Line 584 has weird spacing: '...anaging that ...' ... _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Nov 4 18:57:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24983 for ; Thu, 4 Nov 2004 18:57:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPrjN-0003Eb-QH for iptel-web-archive@ietf.org; Thu, 04 Nov 2004 19:13:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPrIj-0001m8-CU; Thu, 04 Nov 2004 18:45:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPrEi-0000ZH-5d for iptel@megatron.ietf.org; Thu, 04 Nov 2004 18:41:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23705 for ; Thu, 4 Nov 2004 18:41:45 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPrUK-0002rz-QF for iptel@ietf.org; Thu, 04 Nov 2004 18:57:57 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2004 15:52:00 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA4NfFcp029455; Thu, 4 Nov 2004 15:41:15 -0800 (PST) Received: from [10.32.131.248] ([10.32.131.248]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATT05523; Thu, 4 Nov 2004 15:41:14 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Nov 2004 15:41:14 -0800 From: Cullen Jennings To: "iptel@ietf.org" , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Subject: [Iptel] tel-np-02 comments X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Few little NIT like comments on the draft.... If you want help moving it to xml2rfc after IETF to help with formatting, I would be glad to do that. Section 5.2.3 seems a little vague. Do you mean that the rn can be overloaded with the switch id when the rn occurs in a SIP From header? What about P-Asserted-Identity? Examples should have invalid phone number such as 555-1212. CIC should also be invalid. Should discuss when comparing things that all visual-separators are removed. Looks like some formatting issues and has some special characters in it. Move to new boiler plate. ID Nits says idnits 1.34 (28 Jul 2004) draft-ietf-iptel-tel-np-02.txt: Looks like you're using RFC 2026 boilerplate. Better change to RFC 3667/3668. The document seems to add a numbered reference to RFC 2026 to the boilerplate There are 114 instances of too long lines in the document, -- the longest one being 3 characters in excess of 72. There are 13 instances of lines with non-ascii characters in the document. Warnings: The document seems to lack an RFC 2026 Section 10.4(A) Disclaimer The document seems to lack an RFC 2026 Section 10.4(B) IPR Disclosure Invitation There are 5 instances of lines with hyphenated line breaks in the document. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Nov 4 19:06:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25601 for ; Thu, 4 Nov 2004 19:06:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPrrt-0003Qm-Ho for iptel-web-archive@ietf.org; Thu, 04 Nov 2004 19:22:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPraS-00053I-UT; Thu, 04 Nov 2004 19:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPrVF-0004Gs-OX for iptel@megatron.ietf.org; Thu, 04 Nov 2004 18:58:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25180 for ; Thu, 4 Nov 2004 18:58:51 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPrkr-0003Gl-I9 for iptel@ietf.org; Thu, 04 Nov 2004 19:15:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 04 Nov 2004 15:58:52 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA4Nwaom027147; Thu, 4 Nov 2004 15:58:36 -0800 (PST) Received: from [10.32.131.248] ([10.32.131.248]) by mira-sjc5-e.cisco.com (MOS 3.4.5-GR) with ESMTP id ATT07294; Thu, 4 Nov 2004 15:58:34 -0800 (PST) User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 04 Nov 2004 15:58:33 -0800 From: Cullen Jennings To: "iptel@ietf.org" , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Iptel] Few comments on tel-enumdi-00 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Two really trivial and irrelevant comments .... In 3.1, an elements that does not know about this conventions will still end up doing the dip. That makes me wonder if it should be a "SHOULD NOT" instead of "MUST NOT" do a ENUM dip. Just a thought, not sure it makes any difference one way or another. In the examples, should use invalid phone number and example.com instead of provider.net. idnits says "No nits found" :-) Congratulations. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Fri Nov 5 18:51:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02319 for ; Fri, 5 Nov 2004 18:51:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDrM-000819-3G for iptel-web-archive@ietf.org; Fri, 05 Nov 2004 18:51:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDq2-00081g-Ly; Fri, 05 Nov 2004 18:49:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDoA-0007Nq-7y for iptel@megatron.ietf.org; Fri, 05 Nov 2004 18:47:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02004 for ; Fri, 5 Nov 2004 18:47:51 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDoA-0007uP-OV for iptel@ietf.org; Fri, 05 Nov 2004 18:47:55 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 05 Nov 2004 15:47:29 -0800 X-BrightmailFiltered: true Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iA5NlJJZ009500; Fri, 5 Nov 2004 15:47:20 -0800 (PST) Received: from cisco.com ([10.32.131.21]) by vtg-um-e2k2.sj21ad.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Nov 2004 15:47:20 -0800 Message-ID: <418C1107.9030802@cisco.com> Date: Fri, 05 Nov 2004 15:47:19 -0800 From: Manjunath Bangalore User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: X-OriginalArrivalTime: 05 Nov 2004 23:47:20.0073 (UTC) FILETIME=[CA0CD790:01C4C391] X-Spam-Score: 0.5 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff Cc: Dhaval N Shah , Salama , "iptel@ietf.org" , Hussein, rajneesh@cisco.com Subject: [Iptel] Re: tgrep 04 comments X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0500754493==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 --===============0500754493== Content-Type: multipart/alternative; boundary="------------090706010807000100000004" --------------090706010807000100000004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cullen, Thanks for reviewing it. We will incorporate the suggested changes. Regards, -Manjax Cullen Jennings wrote: >I like this document and have read it so many times that I have lost any >objective ability to catch mistakes in it. Anyways, here are some NITS that >come to mind .... > >(PS. If you want me to help convert this to XML2RFC to deal with a bunch of >this, I would be happy to help after IETF) > > >Needs a table of contents as it is over 15 pages. > >Expand first use of TRIP in abstract > >In the Security Section might want to include some of the evil things that >can happen if you don't follow security recommendations in 3219 like DOS of >all phone calls on your network, misrouting of calls, stealing calls meant >for carrier A to carrier B, acceleration of heat death of universe, and so >on. > >Move to new boiler plate. > >Update Jonathans contact info. > >Warning in the introduction that you have to read 3219 for this to make any >sense. > >I don't see the numbers for the new address families. > >Section 3.7.1 had duplicate text abut how CarrierIdCode is formed. Could we >put this in just one place to reduce the chance of having it conflict. > >Split references into Normative and Informative. > >In the IANA section, put something along the lines of .... > >Trash the Changes sections. > > >Update the table at > >http://www.iana.org/assignments/trip-parameters > >to have > >TRIP Attributes >Code Attribute Reference >------- -------------------------- --------- > 14 AvailableCircuits [RFC-AAAA] > > >TRIP Address Families >Code Address Family Reference >----------- --------------------------- --------- > 4 TrunkGroup [RFC-AAAA] > >[Note to RFC Editor - replace RFC-AAAA with this RFC number] > > > >Some spelling typos (or perhaps these are OK and I just don't know the >various ways to spell the work but, for what they are worth) > >57c57 >< turn can propogate that routing information within and between >--- > > >> turn can propagate that routing information within and between >> >> >59c59 >< of similarites with the TRIP Protocol. It has similar procedures and >--- > > >> of similarities with the TRIP Protocol. It has similar procedures and >> >> >158c158 >< and/or propogated by the TRIP Location Server. >--- > > >> and/or propagated by the TRIP Location Server. >> >> >171c171 >< UPDATE message to propogate the routes supported. It uses >--- > > >> UPDATE message to propagate the routes supported. It uses >> >> >202c202 >< speaker sends the reachibility informaton in the UPDATE messages. The >--- > > >> speaker sends the reachibility information in the UPDATE messages. The >> >> >252c252 >< MAY be propogated beyond the LS that receives it. >--- > > >> MAY be propagated beyond the LS that receives it. >> >> >687c687 >< When the scope of a CarrierIdCode is known to be unique apriori, the >--- > > >> When the scope of a CarrierIdCode is known to be unique a priori, the >> >> >844c844 >< When the scope of a CarrierIdCode is known to be unique apriori, the >--- > > >> When the scope of a CarrierIdCode is known to be unique a priori, the >> >> >983c983 >< MUST NOT send UPDATEs of more than one of the following catagories >--- > > >> MUST NOT send UPDATEs of more than one of the following categories >> >> >1076c1076 >< | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW >| >--- > > >> | | (I-TRIP/ | | |t| |d| | Management |-++-+-------| GW | >> >> >1130c1130 >< | | (I-TRIP/ | | |t| |d| | Mangement |-++-+-------| GW >| >--- > > >> | | (I-TRIP/ | | |t| |d| | Management |-++-+-------| GW | >> >> >1181c1181 >< refered to as Consolidation. In the above example, it is possible >--- > > >> referred to as Consolidation. In the above example, it is possible >> >> >1328c1328 >< to accomodate representation of Country codes in association with >--- > > >> to accommodate representation of Country codes in association with >> >> > > > >idnits says ... > >idnits 1.34 (28 Jul 2004) > >/Users/fluffy/id/draft-ietf-iptel-tgrep-04.txt: > > The document seems to lack separate sections for Informative/Normative >References > > * The document claims conformance with section 10 of RFC 2026, but uses > some RFC 3667/3668 boilerplate. As RFC 3667/3668 replaces section 10 of > RFC 2026, you should not claim conformance with it if you have changed > to using RFC 3667/3668 boilerplate. > > Looks like you're using RFC 2026 boilerplate. Better change to RFC >3667/3668. > The document seems to lack an 2026 Section 10.4(C) Copyright Notice > -- however, there's a paragraph with a matching beginning. Boilerplate >error? > The document seems to lack an RFC 2026 Section 10.4(C) Permission Grants >Notice > The document seems to lack an RFC 2026 Section 10.4(C) Disclaimer > -- however, there's a paragraph with a matching beginning. Boilerplate >error? > The document is more than 15 pages and seems to lack a Table of Contents > There are 39 instances of too long lines in the document, > -- the longest one being 22 characters in excess of 72. > > Warnings: > There are 1 instances of lines with hyphenated line breaks in the >document. > > Line 325 has weird spacing: '...s to be deter...' > Line 388 has weird spacing: '...refixes that...' > Line 393 has weird spacing: '...ges may be re...' > Line 466 has weird spacing: '...nkgroup for t...' > Line 584 has weird spacing: '...anaging that ...' > ... > > > > > --------------090706010807000100000004 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cullen,

Thanks for reviewing it. We will incorporate the suggested changes.

Regards,
-Manjax

Cullen Jennings wrote:
I like this document and have read it so many times that I have lost any
objective ability to catch mistakes in it. Anyways, here are some NITS that
come to mind ....

(PS. If you want me to help convert this to XML2RFC to deal with a bunch of
this, I would be happy to help after IETF)


Needs a table of contents as it is over 15 pages.

Expand first use of TRIP in abstract

In the Security Section might want to include some of the evil things that
can happen if you don't follow security recommendations in 3219 like DOS of
all phone calls on your network, misrouting of calls, stealing calls meant
for carrier A to carrier B, acceleration of heat death of universe, and so
on. 

Move to new boiler plate.

Update Jonathans contact info.

Warning in the introduction that you have to read 3219 for this to make any
sense. 

I don't see the numbers for the new address families.

Section 3.7.1 had duplicate text abut how CarrierIdCode is formed. Could we
put this in just one place to reduce the chance of having it conflict.

Split references into Normative and Informative.

In the IANA section, put something along the lines of ....

Trash the Changes sections.


Update the table at

http://www.iana.org/assignments/trip-parameters

to have 

TRIP Attributes
Code      Attribute                       Reference
-------   --------------------------      ---------
     14   AvailableCircuits               [RFC-AAAA]


TRIP Address Families
Code         Address Family               Reference
-----------  ---------------------------  ---------
          4  TrunkGroup                   [RFC-AAAA]

[Note to RFC Editor - replace RFC-AAAA with this RFC number]



Some spelling typos (or perhaps these are OK and I just don't know the
various ways to spell the work but, for what they are worth)

57c57
<    turn can propogate that routing information within and between
---
  
   turn can propagate that routing information within and between
    
59c59
<    of similarites with the TRIP Protocol. It has similar procedures and
---
  
   of similarities with the TRIP Protocol. It has similar procedures and
    
158c158
<    and/or propogated by the TRIP Location Server.
---
  
   and/or propagated by the TRIP Location Server.
    
171c171
<    UPDATE message to propogate the routes supported. It uses
---
  
   UPDATE message to propagate the routes supported. It uses
    
202c202
<    speaker sends the reachibility informaton in the UPDATE messages. The
---
  
   speaker sends the reachibility information in the UPDATE messages. The
    
252c252
<    MAY be propogated beyond the LS that receives it.
---
  
   MAY be propagated beyond the LS that receives it.
    
687c687
<    When the scope of a CarrierIdCode is known to be unique apriori, the
---
  
   When the scope of a CarrierIdCode is known to be unique a priori, the
    
844c844
<    When the scope of a CarrierIdCode is known to be unique apriori, the
---
  
   When the scope of a CarrierIdCode is known to be unique a priori, the
    
983c983
<    MUST NOT send UPDATEs of more than one of the following catagories
---
  
   MUST NOT send UPDATEs of more than one of the following categories
    
1076c1076
<     |   |  (I-TRIP/   |  |     |t|  |d|  |  Mangement  |-++-+-------| GW
|
---
  
    |   |  (I-TRIP/   |  |     |t|  |d|  |  Management  |-++-+-------| GW  |
    
1130c1130
<     |   |  (I-TRIP/   |  |     |t|  |d|  |  Mangement  |-++-+-------| GW
|
---
  
    |   |  (I-TRIP/   |  |     |t|  |d|  |  Management  |-++-+-------| GW  |
    
1181c1181
<    refered to as Consolidation. In the above example, it is possible
---
  
   referred to as Consolidation. In the above example, it is possible
    
1328c1328
<        to accomodate representation of Country codes in association with
---
  
       to accommodate representation of Country codes in association with
    



idnits says ...

idnits 1.34 (28 Jul 2004)

/Users/fluffy/id/draft-ietf-iptel-tgrep-04.txt:

  The document seems to lack separate sections for Informative/Normative
References

  * The document claims conformance with section 10 of RFC 2026, but uses
    some RFC 3667/3668 boilerplate.  As RFC 3667/3668 replaces section 10 of
    RFC 2026, you should not claim conformance with it if you have changed
    to using RFC 3667/3668 boilerplate.

  Looks like you're using RFC 2026 boilerplate. Better change to RFC
3667/3668.
  The document seems to lack an 2026 Section 10.4(C) Copyright Notice
  -- however, there's a paragraph with a matching beginning. Boilerplate
error?
  The document seems to lack an RFC 2026 Section 10.4(C) Permission Grants
Notice
  The document seems to lack an RFC 2026 Section 10.4(C) Disclaimer
  -- however, there's a paragraph with a matching beginning. Boilerplate
error?
  The document is more than 15 pages and seems to lack a Table of Contents
  There are 39 instances of too long lines in the document,
  -- the longest one being 22 characters in excess of 72.

  Warnings:
    There are 1 instances of lines with hyphenated line breaks in the
document. 

    Line 325 has weird spacing: '...s to be  deter...'
    Line 388 has weird spacing: '...refixes  that...'
    Line 393 has weird spacing: '...ges may  be re...'
    Line 466 has weird spacing: '...nkgroup  for t...'
    Line 584 has weird spacing: '...anaging  that ...'
      ...

--------------090706010807000100000004-- --===============0500754493== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0500754493==-- From iptel-bounces@ietf.org Sun Nov 7 12:32:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06757 for ; Sun, 7 Nov 2004 12:32:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQquD-0007mL-Eo for iptel-web-archive@ietf.org; Sun, 07 Nov 2004 12:32:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqpV-0000Fe-Qt; Sun, 07 Nov 2004 12:27:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQqhJ-00073U-P4 for iptel@megatron.ietf.org; Sun, 07 Nov 2004 12:19:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05877 for ; Sun, 7 Nov 2004 12:19:22 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQqhg-0007V0-Ss for iptel@ietf.org; Sun, 07 Nov 2004 12:19:49 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iA7HIm10016148; Sun, 7 Nov 2004 17:18:49 GMT Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id ; Sun, 7 Nov 2004 12:18:48 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED01CC922@stntexch01.cis.neustar.com> From: "Yu, James" To: "'Cullen Jennings'" Date: Sun, 7 Nov 2004 12:18:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: "'iptel@ietf.org'" Subject: [Iptel] RE: tel-np-02 comments X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cullen, Thanks for the comments. Please see the responses inline. I'll send you a revised (temp) I-D in a separate e-mail to see if the additions are OK. James ------ Forwarded Message From: Cullen Jennings Date: Thu, 04 Nov 2004 15:41:14 -0800 To: "iptel@ietf.org" , Subject: tel-np-02 comments Few little NIT like comments on the draft.... If you want help moving it to xml2rfc after IETF to help with formatting, I would be glad to do that. [YU] Yes, please help. Section 5.2.3 seems a little vague. Do you mean that the rn can be overloaded with the switch id when the rn occurs in a SIP From header? What about P-Asserted-Identity? [YU] The I-D focuses on the tel URI so it does not discuss how the signaling protocol such as SIP carries the tel URI. The "rn" goes with the phone number. For a caller, it can be used to indicate the originating switch/caller location. "From" header is a place so is any header that can carry the tel URI. If a GW is using the JIP to formulate the tel URI, then the location of the caller is asserted and P-Asserted-Identity can include the "rn" in the tel URI. I guess that SIP signaling procedures need to define how to formulate the tel URI in various headers. Examples should have invalid phone number such as 555-1212. CIC should also be invalid. [YU] Added cases E, F and G in Section 6. Should discuss when comparing things that all visual-separators are removed. [YU] Added two paragraphs before Section 5.1 about visual-separators and about invalid "rn" and "cic" processing. Looks like some formatting issues and has some special characters in it. Move to new boiler plate. [YU] Please help. ID Nits says idnits 1.34 (28 Jul 2004) draft-ietf-iptel-tel-np-02.txt: Looks like you're using RFC 2026 boilerplate. Better change to RFC 3667/3668. The document seems to add a numbered reference to RFC 2026 to the boilerplate There are 114 instances of too long lines in the document, -- the longest one being 3 characters in excess of 72. [YU] Please indicated which ones must be converted to shorter sentences. There are 13 instances of lines with non-ascii characters in the document. [YU] Please identify specific locations for non-ascii characters. Warnings: The document seems to lack an RFC 2026 Section 10.4(A) Disclaimer The document seems to lack an RFC 2026 Section 10.4(B) IPR Disclosure Invitation [YU] Please help to insert when using the new boiler plate. There are 5 instances of lines with hyphenated line breaks in the document. [YU] Please identify specific locations for non-ascii characters. ------ End of Forwarded Message _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 8 07:34:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28554 for ; Mon, 8 Nov 2004 07:34:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR8jj-00073D-9z for iptel-web-archive@ietf.org; Mon, 08 Nov 2004 07:35:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8ez-0008OL-Lm; Mon, 08 Nov 2004 07:30:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8dI-00087k-8d for iptel@megatron.ietf.org; Mon, 08 Nov 2004 07:28:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27806 for ; Mon, 8 Nov 2004 07:28:27 -0500 (EST) Message-Id: <200411081228.HAA27806@ietf.org> Received: from winwebhosting.com ([67.15.20.8] helo=dx24.winwebhosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR8dn-0006sZ-NN for iptel@ietf.org; Mon, 08 Nov 2004 07:29:02 -0500 Received: from [204.249.176.130] (helo=BROSENLT) by dx24.winwebhosting.com with esmtpa (Exim 4.43) id 1CR8bA-0004HM-Vt; Mon, 08 Nov 2004 06:26:17 -0600 From: "Brian Rosen" To: , Subject: RE: [Iptel] Agenda for iptel meeting Date: Mon, 8 Nov 2004 07:27:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcTA+qaEFvUTqjf8QIudbP5R0SspdQBjUuDAAMGKCvA= In-Reply-To: <5816828233DEFA41807A6CFDFDF2343C3A8C1C@esebe056.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx24.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit I missed the cutoff. I'll submit the update when the I-D editor opens again. Brian > -----Original Message----- > From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of > hisham.khartabil@nokia.com > Sent: Thursday, November 04, 2004 11:07 AM > To: jdrosen@cisco.com > Cc: iptel@ietf.org > Subject: RE: [Iptel] Agenda for iptel meeting > > Myself, Brian and Richard Stastny have been discussing some issues in the > draft but I haven't seen an update reflecting the discussion. When do we > expect to see that version? > > Thanks, > Hisham > > > -----Original Message----- > > From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: 02.November.2004 18:39 > > To: Khartabil Hisham (Nokia-TP-MSW/Helsinki) > > Cc: iptel@ietf.org > > Subject: Re: [Iptel] Agenda for iptel meeting > > > > > > This is a good question. I pinged Brian on this, and his view > > was that > > the plan was to submit to iesg directly; i.e., it didn't require > > becoming an iptel item. I am fine either way; the draft is > > sufficiently > > short that it's not clear it really matters. In either case, > > if you have > > comments, please do make them. It is appropriate for those > > comments to > > be made to the iptel list. > > > > Thanks, > > Jonathan R. > > > > hisham.khartabil@nokia.com wrote: > > > > > Whatever happened to > > http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstri > > ng-00.txt > > > > > > Should we take this to sipping? > > > > > > /Hisham > > > > > > > > >>-----Original Message----- > > >>From: iptel-bounces@ietf.org > > >>[mailto:iptel-bounces@ietf.org]On Behalf Of > > >>ext Jonathan Rosenberg > > >>Sent: 02.November.2004 17:23 > > >>To: list iptel > > >>Subject: [Iptel] Agenda for iptel meeting > > >> > > >> > > >>Folks, > > >> > > >>Here is our agenda for the iptel meeting in D.C. I believe > > >>our time slot > > >>has changed due to the conflict with simple, though this > > does not yet > > >>appear to be reflected in the online schedule. Please stay posted > > >>regarding the specific time. > > >> > > >>Are there any additional items folks would like to see covered? > > >> > > >>IP Telephony WG (IPTEL) > > >> > > >>TUESDAY, November 9, 2004, 1300-1400 > > >>==================================== > > >> > > >>CHAIRS: Jonathan Rosenberg > > >> Cullen Jennings > > >> > > >>AGENDA: > > >> > > >> 5 min Agenda Bashing Chairs > > >> Bluesheet, Scribe > > >> > > >>20 min Enum Indicator Richard Stastny > > >> draft-stastny-iptel-tel-enumdi-00.txt > > >> DNS URL > > >> > > >>30 min Plan for concluding work Chairs Et.Al. > > >> draft-ietf-iptel-tgrep-04.txt > > >> draft-ietf-iptel-tel-np-02.txt > > >> draft-ietf-iptel-trunk-group-02.txt > > >> > > >> > > >>Thanks, > > >>Jonathan R. > > >>-- > > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > >>Director, Service Provider VoIP Architecture Parsippany, NJ > > >>07054-2711 > > >>Cisco Systems > > >>jdrosen@cisco.com FAX: (973) 952-5050 > > >>http://www.jdrosen.net PHONE: (973) 952-5000 > > >>http://www.cisco.com > > >> > > >> > > >>_______________________________________________ > > >>Iptel mailing list > > >>Iptel@ietf.org > > >>https://www1.ietf.org/mailman/listinfo/iptel > > >> > > > > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Director, Service Provider VoIP Architecture Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 9 16:10:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13025 for ; Tue, 9 Nov 2004 16:10:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdGa-0006jl-OR for iptel-web-archive@ietf.org; Tue, 09 Nov 2004 16:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRdAZ-000318-CK; Tue, 09 Nov 2004 16:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRd9l-0002ZW-HW for iptel@megatron.ietf.org; Tue, 09 Nov 2004 16:04:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12510 for ; Tue, 9 Nov 2004 16:03:59 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRdAZ-0006Yf-FO for iptel@ietf.org; Tue, 09 Nov 2004 16:04:52 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2004 13:03:53 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iA9L3Rcj000550 for ; Tue, 9 Nov 2004 13:03:27 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn4-446.cisco.com [10.21.81.190]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFQ09369; Tue, 9 Nov 2004 13:03:25 -0800 (PST) Message-ID: <4191309C.4050005@cisco.com> Date: Tue, 09 Nov 2004 16:03:24 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Iptel] getting group consensus on moving forward with our work items X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Folks, At the iptel meeting today, there was consensus in the room on plans for moving forward with various drafts. I'd like to verify that consensus by asking the list if folks are OK proceeding with the following: * Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears in the archives * Proceed to wglc on http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt immediately following the ietf * adopt http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt as a work item of iptel * do not adopt http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt as a work item. The author will take it directly to IESG as an individual draft. * do not adopt the expired tel cpc draft (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a work item. If folks have a problem that they believe is addressed by this work, please bring that forward in the next few weeks. * tgrep will go to IESG after a revision incorporating comments from Cullen and the pending comments from Jonathan Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 9 17:47:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23482 for ; Tue, 9 Nov 2004 17:47:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRemR-0000m8-Ju for iptel-web-archive@ietf.org; Tue, 09 Nov 2004 17:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRebf-0003iv-Ia; Tue, 09 Nov 2004 17:36:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReRG-0000sg-P1 for iptel@megatron.ietf.org; Tue, 09 Nov 2004 17:26:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21309 for ; Tue, 9 Nov 2004 17:26:08 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReS5-0000Am-CE for iptel@ietf.org; Tue, 09 Nov 2004 17:27:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2004 14:37:19 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA9MPWom018948; Tue, 9 Nov 2004 14:25:33 -0800 (PST) Received: from [10.67.87.214] (sjc-vpn4-412.cisco.com [10.21.81.156]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iA9MQLvv030760; Tue, 9 Nov 2004 14:26:22 -0800 In-Reply-To: <4191309C.4050005@cisco.com> References: <4191309C.4050005@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <432EE114-329E-11D9-A03A-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Iptel] getting group consensus on moving forward with our work items Date: Tue, 9 Nov 2004 17:25:29 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100039182.696884"; x:"432200"; a:"rsa-sha1"; b:"nofws:1934"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"BtzcUxQ/rFUKgmZCnPMUkCcGEwkxWWJD9dXEHr18E6vGqK6dQZdlsQiKA8m1D" "J1A08C9ZSJsLK7bsyrmF0EMYWwXj6gTQSf4Q0fqcv0VyIjDwoyuzQ9b/dLMgR" "wtKFRgoZO0X1ahlsKkKH928VNwW2Dc3C6KNldtf8BTH/wo3w4="; c:"From: David R Oran "; c:"Subject: Re: [Iptel] getting group consensus on moving forward with ou" "r work items"; c:"Date: Tue, 9 Nov 2004 17:25:29 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: list iptel X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit i am fine with all these proposed actions. Dave. On Nov 9, 2004, at 4:03 PM, Jonathan Rosenberg wrote: > Folks, > > At the iptel meeting today, there was consensus in the room on plans > for moving forward with various drafts. I'd like to verify that > consensus by asking the list if folks are OK proceeding with the > following: > > * Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears > in the archives > > * Proceed to wglc on > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group > -02.txt immediately following the ietf > > * adopt > http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi > -00.txt as a work item of iptel > > * do not adopt > http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring > -00.txt as a work item. The author will take it directly to IESG as an > individual draft. > > * do not adopt the expired tel cpc draft > (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a > work item. If folks have a problem that they believe is addressed by > this work, please bring that forward in the next few weeks. > > * tgrep will go to IESG after a revision incorporating comments from > Cullen and the pending comments from Jonathan > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 9 17:48:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23627 for ; Tue, 9 Nov 2004 17:48:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRenK-0000nx-Gm for iptel-web-archive@ietf.org; Tue, 09 Nov 2004 17:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRebk-0003ob-89; Tue, 09 Nov 2004 17:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReRr-0000yv-EU for iptel@megatron.ietf.org; Tue, 09 Nov 2004 17:26:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21353 for ; Tue, 9 Nov 2004 17:26:44 -0500 (EST) Received: from mailout.excelswitching.com ([208.236.123.107]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CReSh-0000Cp-7M for iptel@ietf.org; Tue, 09 Nov 2004 17:27:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] getting group consensus on moving forward with our workitems Date: Tue, 9 Nov 2004 17:26:16 -0500 Message-ID: <656BE56E7D48F6419054CC1C81114927014CD7D3@exch01.corp.xl.com> Thread-Topic: [Iptel] getting group consensus on moving forward with our workitems Thread-Index: AcTGoJOBTJrjJqzOSl24EVZlkN/yOQACYs+A From: "Jain, Rajnish" To: "Jonathan Rosenberg" , "list iptel" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Jonathan, Based on our implementation experience of the trunk-group I-D, I'd suggest we proceed w/ the I-D.=20 Thanks, Rajnish -----Original Message----- From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, November 09, 2004 4:03 PM To: list iptel Subject: [Iptel] getting group consensus on moving forward with our workitems Folks, At the iptel meeting today, there was consensus in the room on plans for moving forward with various drafts. I'd like to verify that consensus by asking the list if folks are OK proceeding with the following: * Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears in the archives * Proceed to wglc on http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt immediately following the ietf * adopt http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.tx t as a work item of iptel * do not adopt http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt as a work item. The author will take it directly to IESG as an individual draft. * do not adopt the expired tel cpc draft (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a work item. If folks have a problem that they believe is addressed by this work, please bring that forward in the next few weeks. * tgrep will go to IESG after a revision incorporating comments from Cullen and the pending comments from Jonathan Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 9 20:37:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08589 for ; Tue, 9 Nov 2004 20:37:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRhQx-0004NT-LW for iptel-web-archive@ietf.org; Tue, 09 Nov 2004 20:38:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRhM9-0002uZ-KW; Tue, 09 Nov 2004 20:33:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRhIX-0002Oq-0F for iptel@megatron.ietf.org; Tue, 09 Nov 2004 20:29:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07728 for ; Tue, 9 Nov 2004 20:29:19 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRhJO-00048S-3e for iptel@ietf.org; Tue, 09 Nov 2004 20:30:14 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAA1ShW11783; Tue, 9 Nov 2004 20:28:43 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Nov 2004 20:28:44 -0500 Message-ID: From: "Mary Barnes" To: "'Jonathan Rosenberg'" , list iptel Subject: RE: [Iptel] getting group consensus on moving forward with our wo rkitems Date: Tue, 9 Nov 2004 20:28:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1183293708==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1183293708== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C6C4.9A74D15A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4C6C4.9A74D15A Content-Type: text/plain I wasn't able to attend IPTEL since it was scheduled MIDCOM, so I appreciate this summary to the list. I'm fine with this proposal. I reviewed tgrep about 18 mos. ago and it had suggested various editorial changes, which have been incorporated and since there doesn't seem to have been any major content change (per the change summaries), I think the major change to that doc would be updating the template. Regards, Mary H. Barnes IP Multimedia Standards Strategy ESN 444-5432 (972-684-5432) sip: mbarnes@techtrial.com -----Original Message----- From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Tuesday, November 09, 2004 3:03 PM To: list iptel Subject: [Iptel] getting group consensus on moving forward with our workitems Folks, At the iptel meeting today, there was consensus in the room on plans for moving forward with various drafts. I'd like to verify that consensus by asking the list if folks are OK proceeding with the following: * Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears in the archives * Proceed to wglc on http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt immediately following the ietf * adopt http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt as a work item of iptel * do not adopt http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt as a work item. The author will take it directly to IESG as an individual draft. * do not adopt the expired tel cpc draft (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a work item. If folks have a problem that they believe is addressed by this work, please bring that forward in the next few weeks. * tgrep will go to IESG after a revision incorporating comments from Cullen and the pending comments from Jonathan Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel ------_=_NextPart_001_01C4C6C4.9A74D15A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Iptel] getting group consensus on moving forward with our = workitems

I wasn't able to attend IPTEL since it was scheduled = MIDCOM, so I appreciate this summary to the list.  

I'm fine with this proposal. 

I reviewed tgrep about 18 mos. ago and it had = suggested various editorial changes, which have been incorporated and = since there doesn't seem to have been any major content change (per the = change summaries), I think the major change to that doc would be = updating the template.

Regards,
Mary H. Barnes
IP Multimedia Standards Strategy
ESN 444-5432 (972-684-5432)
sip: mbarnes@techtrial.com


-----Original Message-----
From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org= ] On Behalf Of Jonathan Rosenberg
Sent: Tuesday, November 09, 2004 3:03 PM
To: list iptel
Subject: [Iptel] getting group consensus on moving = forward with our workitems


Folks,

At the iptel meeting today, there was consensus in = the room on plans for
moving forward with various drafts. I'd like to = verify that consensus by
asking the list if folks are OK proceeding with the = following:

* Proceed to wglc on draft-ietf-iptel-tel-np once a = revision appears in
the archives

* Proceed to wglc on
http://www.ietf.org/internet-drafts/draft-ietf-iptel-t= runk-group-02.txt
immediately following the ietf

* adopt
http://www.ietf.org/internet-drafts/draft-stastny-ipte= l-tel-enumdi-00.txt
as a work item of iptel

* do not adopt
http://www.ietf.org/internet-drafts/draft-rosen-iptel-= dialstring-00.txt
as a work item. The author will take it directly to = IESG as an
individual draft.

* do not adopt the expired tel cpc draft
(http://www.watersprings.org/pub/id/draft-mahy-iptel-cp= c-01.txt) as a
work item. If folks have a problem that they believe = is addressed by
this work, please bring that forward in the next few = weeks.

* tgrep will go to IESG after a revision = incorporating comments from
Cullen and the pending comments from Jonathan

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, = Ph.D.           &= nbsp;       600 Lanidex Plaza
Director, Service Provider VoIP = Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com       &nbs= p;           &nbs= p;          = FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;        PHONE: (973) = 952-5000
http://www.cisco.com


_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www1.ietf.org/mailman/listinfo/iptel

------_=_NextPart_001_01C4C6C4.9A74D15A-- --===============1183293708== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1183293708==-- From iptel-bounces@ietf.org Fri Nov 12 16:21:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27312 for ; Fri, 12 Nov 2004 16:21:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSisF-0006yl-A6 for iptel-web-archive@ietf.org; Fri, 12 Nov 2004 16:22:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSig7-0005Vl-Ba; Fri, 12 Nov 2004 16:09:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSiLa-0003gl-Fs for iptel@megatron.ietf.org; Fri, 12 Nov 2004 15:48:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18774 for ; Fri, 12 Nov 2004 15:48:40 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CSiN1-00046w-Km for iptel@ietf.org; Fri, 12 Nov 2004 15:50:11 -0500 Received: (qmail 31444 invoked by uid 1014); 12 Nov 2004 20:48:10 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.035301 secs); 12 Nov 2004 20:48:10 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 12 Nov 2004 20:48:10 -0000 From: "Shan Lu" To: "'list iptel'" Subject: Comments on Trunk Group ID and RE: [Iptel] getting group consensus on moving forward with our workitems Date: Fri, 12 Nov 2004 15:49:26 -0500 Message-ID: <01ac01c4c8f9$1939d950$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-reply-to: <4191309C.4050005@cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable I support the plan to move forward with the trunk group draft. In fact, = my company intends to implement it.=20 However, I do believe there exists a technical hole in the draft, which = I raised on the list before. That is, since "tgrp" is defined as a tel-uri parameter, it can not exist on its own without the actual tel-uri = number. In the case of originating trunk group (ie. PSTN-to-IP direction), the = calling number may be absent. The question is then how to express originating = trunk group. Thanks, Shan Lu =20 >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 >On Behalf Of Jonathan Rosenberg >Sent: Tuesday, November 09, 2004 4:03 PM >To: list iptel >Subject: [Iptel] getting group consensus on moving forward=20 >with our workitems > > >Folks, > >At the iptel meeting today, there was consensus in the room on=20 >plans for=20 >moving forward with various drafts. I'd like to verify that=20 >consensus by=20 >asking the list if folks are OK proceeding with the following: > >* Proceed to wglc on draft-ietf-iptel-tel-np once a revision=20 >appears in=20 >the archives > >* Proceed to wglc on=20 >http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-grou p-02.txt=20 immediately following the ietf * adopt=20 http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt= =20 as a work item of iptel * do not adopt=20 http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt=20 as a work item. The author will take it directly to IESG as an=20 individual draft. * do not adopt the expired tel cpc draft=20 (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a=20 work item. If folks have a problem that they believe is addressed by=20 this work, please bring that forward in the next few weeks. * tgrep will go to IESG after a revision incorporating comments from=20 Cullen and the pending comments from Jonathan Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 15 05:26:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13659 for ; Mon, 15 Nov 2004 05:26:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTe6T-0003vt-Dp for iptel-web-archive@ietf.org; Mon, 15 Nov 2004 05:28:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTe2k-0005bd-WE; Mon, 15 Nov 2004 05:25:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTdyk-0005Mt-Dv for iptel@megatron.ietf.org; Mon, 15 Nov 2004 05:20:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13428 for ; Mon, 15 Nov 2004 05:20:55 -0500 (EST) Received: from usjk1001.kddi.com ([211.4.169.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTe0Y-0003pv-7w for iptel@ietf.org; Mon, 15 Nov 2004 05:23:00 -0500 Received: from usjk1005.kddi.com (usjk1005 [10.96.2.2]) by usjk1001.kddi.com with ESMTP id iAFAKCE20664; Mon, 15 Nov 2004 19:20:12 +0900 (JST) Received: from usjk1039 (localhost [127.0.0.1]) by usjk1005.kddi.com with SMTP id iAFAKCq13804; Mon, 15 Nov 2004 19:20:12 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041115102010.KEJ24157.usjk1009.kddi.com@KDDI-0403PC0002>; Mon, 15 Nov 2004 19:20:10 +0900 To: jdrosen@cisco.com, iptel@ietf.org Subject: Re: [Iptel] getting group consensus on moving forward with our workitems From: Takuya Sawada References: <4191309C.4050005@cisco.com> In-Reply-To: <4191309C.4050005@cisco.com> Message-Id: <200411151920.CJG55248.-EXBUBVBT@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Mon, 15 Nov 2004 19:20:10 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0411151920100000210555 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hi, I am not so happy to hear that cpc work will not move forward. At least when interworking with ISUP or emulating the legacy PSTN, cpc parameter seems to me to be useful. For example, cpc=test paramter in P-Asserted-Identity header may indicate that it is a test call so that it uses testing routing table and is free of charge through the connection. With cpc=priority, it can express it requires the call handling with priority. (This should be done with R-P header, though) With cpc=payphone, it may require to apply special charge rate, etc. The scope of cpc work is probably limited to the legacy concept but is useful in a certain situation. Is it possible to move this forward to make an RFC as a working group item, or as an individual submission? Regards, Takuya > Folks, > > At the iptel meeting today, there was consensus in the room on plans for > moving forward with various drafts. I'd like to verify that consensus by > asking the list if folks are OK proceeding with the following: > > * Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears in > the archives > > * Proceed to wglc on > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt > immediately following the ietf > > * adopt > http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt > as a work item of iptel > > * do not adopt > http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt > as a work item. The author will take it directly to IESG as an > individual draft. > > * do not adopt the expired tel cpc draft > (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a > work item. If folks have a problem that they believe is addressed by > this work, please bring that forward in the next few weeks. > > * tgrep will go to IESG after a revision incorporating comments from > Cullen and the pending comments from Jonathan > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 15 08:14:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23361 for ; Mon, 15 Nov 2004 08:14:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTgiR-0006qA-DK for iptel-web-archive@ietf.org; Mon, 15 Nov 2004 08:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTgcb-0006Km-Fs; Mon, 15 Nov 2004 08:10:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTgYZ-0005RR-Gm for iptel@megatron.ietf.org; Mon, 15 Nov 2004 08:06:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22684 for ; Mon, 15 Nov 2004 08:06:06 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTgaZ-0006cA-Bz for iptel@ietf.org; Mon, 15 Nov 2004 08:08:11 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 15 Nov 2004 05:06:00 -0800 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iAFD5Sls024289; Mon, 15 Nov 2004 05:05:33 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAFD5sgr032445; Mon, 15 Nov 2004 05:05:55 -0800 In-Reply-To: <01ac01c4c8f9$1939d950$eb00000a@SAJAK> References: <01ac01c4c8f9$1939d950$eb00000a@SAJAK> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <047CBC86-3707-11D9-97C5-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: Comments on Trunk Group ID and RE: [Iptel] getting group consensus on moving forward with our workitems Date: Mon, 15 Nov 2004 08:05:26 -0500 To: "Shan Lu" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100523955.873296"; x:"432200"; a:"rsa-sha1"; b:"nofws:2951"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"iQf/K8sfY2dfq+rRCpIup+1FoJ0IcVGVzrOc2V14NWcYVeH23XF0RlmQ1dT+3" "YNXaZPNLAHLe61KZ3296bbjy3fLH5ZLE32FCATt5dOVerM7Pcu9FoV0xcqcy3" "WCFftPddGBLrqvY9vwDuuGMV73DVfMuZVHuWPe+e/CRhFfVyE="; c:"From: David R Oran "; c:"Subject: Re: Comments on Trunk Group ID and RE: [Iptel] getting group " "consensus on moving forward with our workitems"; c:"Date: Mon, 15 Nov 2004 08:05:26 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: "'list iptel'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Is tel:;tgrp=foo not a valid tel: url? If not, it ought to be. On Nov 12, 2004, at 3:49 PM, Shan Lu wrote: > I support the plan to move forward with the trunk group draft. In > fact, my > company intends to implement it. > > However, I do believe there exists a technical hole in the draft, > which I > raised on the list before. That is, since "tgrp" is defined as a > tel-uri > parameter, it can not exist on its own without the actual tel-uri > number. In > the case of originating trunk group (ie. PSTN-to-IP direction), the > calling > number may be absent. The question is then how to express originating > trunk > group. > > Thanks, > > Shan Lu > >> -----Original Message----- >> From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >> On Behalf Of Jonathan Rosenberg >> Sent: Tuesday, November 09, 2004 4:03 PM >> To: list iptel >> Subject: [Iptel] getting group consensus on moving forward >> with our workitems >> >> >> Folks, >> >> At the iptel meeting today, there was consensus in the room on >> plans for >> moving forward with various drafts. I'd like to verify that >> consensus by >> asking the list if folks are OK proceeding with the following: >> >> * Proceed to wglc on draft-ietf-iptel-tel-np once a revision >> appears in >> the archives >> >> * Proceed to wglc on >> http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-grou > p-02.txt > immediately following the ietf > > * adopt > http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi > -00.txt > as a work item of iptel > > * do not adopt > http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt > as a work item. The author will take it directly to IESG as an > individual draft. > > * do not adopt the expired tel cpc draft > (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a > work item. If folks have a problem that they believe is addressed by > this work, please bring that forward in the next few weeks. > > * tgrep will go to IESG after a revision incorporating comments from > Cullen and the pending comments from Jonathan > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 15 09:39:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28318 for ; Mon, 15 Nov 2004 09:39:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTi2x-0008Ne-Vj for iptel-web-archive@ietf.org; Mon, 15 Nov 2004 09:41:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CThug-0008RU-La; Mon, 15 Nov 2004 09:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CThtr-0008ED-KB for iptel@megatron.ietf.org; Mon, 15 Nov 2004 09:32:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27831 for ; Mon, 15 Nov 2004 09:32:09 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CThvs-0008Dg-1H for iptel@ietf.org; Mon, 15 Nov 2004 09:34:16 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAFEVbai004657; Mon, 15 Nov 2004 08:31:37 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iAFEVbo14069; Mon, 15 Nov 2004 08:31:37 -0600 (CST) Message-ID: <4198BDA1.8090804@lucent.com> Date: Mon, 15 Nov 2004 08:30:57 -0600 From: "Vijay K. Gurbani" Organization: Wireless Research and Development/Internet Software and Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu Subject: Re: Comments on Trunk Group ID and RE: [Iptel] getting group consensus on moving forward with our workitems References: <01ac01c4c8f9$1939d950$eb00000a@SAJAK> In-Reply-To: <01ac01c4c8f9$1939d950$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "'list iptel'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Shan Lu wrote: > I support the plan to move forward with the trunk group > draft. In fact, my company intends to implement it. Shan Lu: Thanks. > However, I do believe there exists a technical hole in the > draft, which I raised on the list before. That is, since > "tgrp" is defined as a tel-uri parameter, it can not exist on > its own without the actual tel-uri number. In the case of > originating trunk group (ie. PSTN-to-IP direction), the calling > number may be absent. The question is then how to express > originating trunk group. I am trying to understand the question better: Is it a requirement in your network that the trunk group be preserved even if the calling party number was absent? Furthermore, how pervasive is this situation in general? Clearly, if it is not, then we do the most minimal on this (probably adding some text on what to do if the calling party number is absent). If it is a pervasive situation, we can spend some capital trying to figure out a way to combat this. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 15 10:13:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01410 for ; Mon, 15 Nov 2004 10:13:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTiaL-0000ci-SS for iptel-web-archive@ietf.org; Mon, 15 Nov 2004 10:16:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTiVb-0000mD-7m; Mon, 15 Nov 2004 10:11:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTiSW-00080K-6Z for iptel@megatron.ietf.org; Mon, 15 Nov 2004 10:08:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00524 for ; Mon, 15 Nov 2004 10:07:58 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CTiUQ-0000Tm-8k for iptel@ietf.org; Mon, 15 Nov 2004 10:10:05 -0500 Received: (qmail 510 invoked by uid 1014); 15 Nov 2004 15:07:16 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.036312 secs); 15 Nov 2004 15:07:16 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 15 Nov 2004 15:07:16 -0000 From: "Shan Lu" To: "'list iptel'" Subject: RE: Comments on Trunk Group ID and RE: [Iptel] getting groupconsensus on moving forward with our workitems Date: Mon, 15 Nov 2004 10:08:31 -0500 Message-ID: <027601c4cb24$f867cd30$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-reply-to: <047CBC86-3707-11D9-97C5-000A95C73842@cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Dave, Based on 2806bis-09, tel:;tgrp=foo is not valid. I am on the fence whether it ought to be. Thanks, Shan Lu >From draft-ietf-iptel-rfc2806bis-09: telephone-uri = "tel:" telephone-subscriber telephone-subscriber = global-number / local-number global-number = global-number-digits *par local-number = local-number-digits *par context *par global-number-digits = "+" 1*phonedigit local-number-digits = 1*phonedigit-hex >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >On Behalf Of David R Oran >Sent: Monday, November 15, 2004 8:05 AM >To: Shan Lu >Cc: 'list iptel' >Subject: Re: Comments on Trunk Group ID and RE: [Iptel] >getting groupconsensus on moving forward with our workitems > > >Is tel:;tgrp=foo not a valid tel: url? >If not, it ought to be. > >On Nov 12, 2004, at 3:49 PM, Shan Lu wrote: > >> I support the plan to move forward with the trunk group draft. In >> fact, my >> company intends to implement it. >> >> However, I do believe there exists a technical hole in the draft, >> which I >> raised on the list before. That is, since "tgrp" is defined as a >> tel-uri >> parameter, it can not exist on its own without the actual tel-uri >> number. In >> the case of originating trunk group (ie. PSTN-to-IP direction), the >> calling >> number may be absent. The question is then how to express >originating >> trunk >> group. >> >> Thanks, >> >> Shan Lu >> >>> -----Original Message----- >>> From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >>> On Behalf Of Jonathan Rosenberg >>> Sent: Tuesday, November 09, 2004 4:03 PM >>> To: list iptel >>> Subject: [Iptel] getting group consensus on moving forward >>> with our workitems >>> >>> >>> Folks, >>> >>> At the iptel meeting today, there was consensus in the room on >>> plans for >>> moving forward with various drafts. I'd like to verify that >>> consensus by >>> asking the list if folks are OK proceeding with the following: >>> >>> * Proceed to wglc on draft-ietf-iptel-tel-np once a revision >>> appears in >>> the archives >>> >>> * Proceed to wglc on >>> http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-grou >> p-02.txt >> immediately following the ietf >> >> * adopt >> http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi >> -00.txt >> as a work item of iptel >> >> * do not adopt >> >http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt >> as a work item. The author will take it directly to IESG as an >> individual draft. >> >> * do not adopt the expired tel cpc draft >> (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a >> work item. If folks have a problem that they believe is addressed by >> this work, please bring that forward in the next few weeks. >> >> * tgrep will go to IESG after a revision incorporating comments from >> Cullen and the pending comments from Jonathan >> >> Thanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >David R. Oran >Cisco Fellow >Cisco Systems >7 Ladyslipper Lane >Acton, MA 01720 USA >Tel: +1 978 264 2048 >Email: oran@cisco.com > > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 15 10:50:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04357 for ; Mon, 15 Nov 2004 10:50:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTj9c-0001HT-EU for iptel-web-archive@ietf.org; Mon, 15 Nov 2004 10:52:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTj61-0007U7-At; Mon, 15 Nov 2004 10:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTj2a-000791-G2 for iptel@megatron.ietf.org; Mon, 15 Nov 2004 10:45:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04032 for ; Mon, 15 Nov 2004 10:45:14 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CTj4a-0001BW-R1 for iptel@ietf.org; Mon, 15 Nov 2004 10:47:22 -0500 Received: (qmail 7033 invoked by uid 1014); 15 Nov 2004 15:44:44 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.034931 secs); 15 Nov 2004 15:44:44 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 15 Nov 2004 15:44:44 -0000 From: "Shan Lu" To: "'Vijay K. Gurbani'" Subject: RE: Comments on Trunk Group ID and RE: [Iptel] getting group consensuson moving forward with our workitems Date: Mon, 15 Nov 2004 10:45:59 -0500 Message-ID: <027701c4cb2a$34119910$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-reply-to: <4198BDA1.8090804@lucent.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: "'list iptel'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Vijay, Thanks for your response. As you are aware, there are two scenarios where the originating number = may be absent. PSTN may withhold the number or the PSTN-SIP gateway may not entrust downstrem endpoints with the number in case of calling party privacy. We have seen both cases and the need to know the incoming PSTN trunk = group when calling number is missing. In a lot applications, originating PSTN trunk group info can be very useful for routing and revealing such info = is often not deemed to be a problem for privacy. I am happy with the draft as far as destination TG is concerned. But I = don't think it should prescribe a formula for originating TG whose validity is sometimes questionable. Thanks, Shan Lu=20 >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 >On Behalf Of Vijay K. Gurbani >Sent: Monday, November 15, 2004 9:31 AM >To: Shan Lu >Cc: 'list iptel' >Subject: Re: Comments on Trunk Group ID and RE: [Iptel]=20 >getting group consensuson moving forward with our workitems > > >Shan Lu wrote: > >> I support the plan to move forward with the trunk group=20 >> draft. In fact, my company intends to implement it.=20 > >Shan Lu: > >Thanks. > >> However, I do believe there exists a technical hole in the=20 >> draft, which I raised on the list before. That is, since=20 >> "tgrp" is defined as a tel-uri parameter, it can not exist on=20 >> its own without the actual tel-uri number. In the case of=20 >> originating trunk group (ie. PSTN-to-IP direction), the calling >> number may be absent. The question is then how to express=20 >> originating trunk group. > >I am trying to understand the question better: Is it a >requirement in your network that the trunk group be >preserved even if the calling party number was absent? >Furthermore, how pervasive is this situation in general? > >Clearly, if it is not, then we do the most minimal on >this (probably adding some text on what to do if the calling >party number is absent). If it is a pervasive situation, >we can spend some capital trying to figure out a way to >combat this. > >Thanks, > >- vijay >--=20 >Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >Wireless Networks Group/Internet Software and Services >Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 >Naperville, Illinois 60566 Voice: +1 630 224 0216 > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 15 10:54:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04494 for ; Mon, 15 Nov 2004 10:54:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTjDA-0001Ke-CX for iptel-web-archive@ietf.org; Mon, 15 Nov 2004 10:56:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTj94-00080Z-JM; Mon, 15 Nov 2004 10:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTj8i-0007vY-7M for iptel@megatron.ietf.org; Mon, 15 Nov 2004 10:51:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04407 for ; Mon, 15 Nov 2004 10:51:34 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CTjAj-0001I9-Mu for iptel@ietf.org; Mon, 15 Nov 2004 10:53:42 -0500 Received: (qmail 8198 invoked by uid 1014); 15 Nov 2004 15:51:05 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.03697 secs); 15 Nov 2004 15:51:05 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 15 Nov 2004 15:51:05 -0000 From: "Shan Lu" To: "'list iptel'" Subject: RE: Comments on Trunk Group ID and RE: [Iptel] getting groupconsensuson moving forward with our workitems Date: Mon, 15 Nov 2004 10:52:20 -0500 Message-ID: <027801c4cb2b$17201fb0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-reply-to: <027601c4cb24$f867cd30$eb00000a@SAJAK> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit Gone thru 2806bis-09 one more time, global-number-digits and local-number-digits are defined as: global-number-digits = "+" 1*phonedigit local-number-digits = 1*phonedigit-hex phonedigit = DIGIT / [ visual-separator ] phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] visual-separator = "-" / "." / "(" / ")" So would this be valid: "tel:-;tgrp=foo"? Thanks, Shan Lu >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >On Behalf Of Shan Lu >Sent: Monday, November 15, 2004 10:09 AM >To: 'list iptel' >Subject: RE: Comments on Trunk Group ID and RE: [Iptel] >getting groupconsensuson moving forward with our workitems > > >Dave, > >Based on 2806bis-09, tel:;tgrp=foo is not valid. I am on the >fence whether >it ought to be. > >Thanks, Shan Lu > >>From draft-ietf-iptel-rfc2806bis-09: > > telephone-uri = "tel:" telephone-subscriber > telephone-subscriber = global-number / local-number > global-number = global-number-digits *par > local-number = local-number-digits *par context *par > > global-number-digits = "+" 1*phonedigit > local-number-digits = 1*phonedigit-hex > >>-----Original Message----- >>From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >>On Behalf Of David R Oran >>Sent: Monday, November 15, 2004 8:05 AM >>To: Shan Lu >>Cc: 'list iptel' >>Subject: Re: Comments on Trunk Group ID and RE: [Iptel] >>getting groupconsensus on moving forward with our workitems >> >> >>Is tel:;tgrp=foo not a valid tel: url? >>If not, it ought to be. >> >>On Nov 12, 2004, at 3:49 PM, Shan Lu wrote: >> >>> I support the plan to move forward with the trunk group draft. In >>> fact, my >>> company intends to implement it. >>> >>> However, I do believe there exists a technical hole in the draft, >>> which I >>> raised on the list before. That is, since "tgrp" is defined as a >>> tel-uri >>> parameter, it can not exist on its own without the actual tel-uri >>> number. In >>> the case of originating trunk group (ie. PSTN-to-IP >direction), the >>> calling >>> number may be absent. The question is then how to express >>originating >>> trunk >>> group. >>> >>> Thanks, >>> >>> Shan Lu >>> >>>> -----Original Message----- >>>> From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >>>> On Behalf Of Jonathan Rosenberg >>>> Sent: Tuesday, November 09, 2004 4:03 PM >>>> To: list iptel >>>> Subject: [Iptel] getting group consensus on moving forward >>>> with our workitems >>>> >>>> >>>> Folks, >>>> >>>> At the iptel meeting today, there was consensus in the room on >>>> plans for >>>> moving forward with various drafts. I'd like to verify that >>>> consensus by >>>> asking the list if folks are OK proceeding with the following: >>>> >>>> * Proceed to wglc on draft-ietf-iptel-tel-np once a revision >>>> appears in >>>> the archives >>>> >>>> * Proceed to wglc on >>>> http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-grou >>> p-02.txt >>> immediately following the ietf >>> >>> * adopt >>> http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi >>> -00.txt >>> as a work item of iptel >>> >>> * do not adopt >>> >>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstri >ng-00.txt >>> as a work item. The author will take it directly to IESG as an >>> individual draft. >>> >>> * do not adopt the expired tel cpc draft >>> >(http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a >>> work item. If folks have a problem that they believe is addressed by >>> this work, please bring that forward in the next few weeks. >>> >>> * tgrep will go to IESG after a revision incorporating comments from >>> Cullen and the pending comments from Jonathan >>> >>> Thanks, >>> Jonathan R. >>> -- >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>> Director, Service Provider VoIP Architecture Parsippany, NJ >>> 07054-2711 >>> Cisco Systems >>> jdrosen@cisco.com FAX: (973) 952-5050 >>> http://www.jdrosen.net PHONE: (973) 952-5000 >>> http://www.cisco.com >>> >>> >>> _______________________________________________ >>> Iptel mailing list >>> Iptel@ietf.org >>> https://www1.ietf.org/mailman/listinfo/iptel >>> >>> >>> _______________________________________________ >>> Iptel mailing list >>> Iptel@ietf.org >>> https://www1.ietf.org/mailman/listinfo/iptel >>> >>David R. Oran >>Cisco Fellow >>Cisco Systems >>7 Ladyslipper Lane >>Acton, MA 01720 USA >>Tel: +1 978 264 2048 >>Email: oran@cisco.com >> >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel >> > > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 15 21:54:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11150 for ; Mon, 15 Nov 2004 21:54:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTtWL-0000z5-IY for iptel-web-archive@ietf.org; Mon, 15 Nov 2004 21:56:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtTb-0001dX-FX; Mon, 15 Nov 2004 21:53:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtS5-0001Sf-0u for iptel@megatron.ietf.org; Mon, 15 Nov 2004 21:52:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10875 for ; Mon, 15 Nov 2004 21:52:15 -0500 (EST) Received: from usjk1001.kddi.com ([211.4.169.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTtU1-0000uF-J8 for iptel@ietf.org; Mon, 15 Nov 2004 21:54:28 -0500 Received: from usjk1005.kddi.com (usjk1005 [10.96.2.2]) by usjk1001.kddi.com with ESMTP id iAG2pVE12819; Tue, 16 Nov 2004 11:51:31 +0900 (JST) Received: from usjk1038 (localhost [127.0.0.1]) by usjk1005.kddi.com with SMTP id iAG2pVq18502; Tue, 16 Nov 2004 11:51:31 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041116025125.DUTY12322.usjk1010.kddi.com@KDDI-0403PC0002>; Tue, 16 Nov 2004 11:51:25 +0900 To: shanlu@sentito.com, iptel@ietf.org Subject: Re: Comments on Trunk Group ID and RE: [Iptel] gettinggroupconsensuson moving forward with our workitems From: Takuya Sawada References: <027601c4cb24$f867cd30$eb00000a@SAJAK> <027801c4cb2b$17201fb0$eb00000a@SAJAK> In-Reply-To: <027801c4cb2b$17201fb0$eb00000a@SAJAK> Message-Id: <200411161151.IAH33646.EBXU-BTVB@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Tue, 16 Nov 2004 11:51:26 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0411161151250000108490 X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Hi, As per ABNF in 2806bis, local-number format MUST have phone-context parameter. So, for example, tel:-;phone-context=gateway.example.com;tgrp=foo conforms to the rule in 2806bis. You can reserve any number format for void-number, "-" or "####" or whatever, under an administrative domain, e.g. "gateway.example.com". I think this is an acceptable solution because tgrp draft says in 4.2; "The use of the "phone-context" parameter in conjunction with this draft is mandatory". If we still want global void-number format for tel URI to indicate tel-related properties without number, we need some more work in 2806bis. (This can be used with cpc parameter, if adopted.) Regards, Takuya Sawada > Gone thru 2806bis-09 one more time, global-number-digits and > local-number-digits are defined as: > > global-number-digits = "+" 1*phonedigit > local-number-digits = 1*phonedigit-hex > > phonedigit = DIGIT / [ visual-separator ] > phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] > visual-separator = "-" / "." / "(" / ")" > > So would this be valid: "tel:-;tgrp=foo"? > > Thanks, Shan Lu > > >-----Original Message----- > >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] > >On Behalf Of Shan Lu > >Sent: Monday, November 15, 2004 10:09 AM > >To: 'list iptel' > >Subject: RE: Comments on Trunk Group ID and RE: [Iptel] > >getting groupconsensuson moving forward with our workitems > > > > > >Dave, > > > >Based on 2806bis-09, tel:;tgrp=foo is not valid. I am on the > >fence whether > >it ought to be. > > > >Thanks, Shan Lu > > > >>From draft-ietf-iptel-rfc2806bis-09: > > > > telephone-uri = "tel:" telephone-subscriber > > telephone-subscriber = global-number / local-number > > global-number = global-number-digits *par > > local-number = local-number-digits *par context *par > > > > global-number-digits = "+" 1*phonedigit > > local-number-digits = 1*phonedigit-hex > > > >>-----Original Message----- > >>From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] > >>On Behalf Of David R Oran > >>Sent: Monday, November 15, 2004 8:05 AM > >>To: Shan Lu > >>Cc: 'list iptel' > >>Subject: Re: Comments on Trunk Group ID and RE: [Iptel] > >>getting groupconsensus on moving forward with our workitems > >> > >> > >>Is tel:;tgrp=foo not a valid tel: url? > >>If not, it ought to be. > >> > >>On Nov 12, 2004, at 3:49 PM, Shan Lu wrote: > >> > >>> I support the plan to move forward with the trunk group draft. In > >>> fact, my > >>> company intends to implement it. > >>> > >>> However, I do believe there exists a technical hole in the draft, > >>> which I > >>> raised on the list before. That is, since "tgrp" is defined as a > >>> tel-uri > >>> parameter, it can not exist on its own without the actual tel-uri > >>> number. In > >>> the case of originating trunk group (ie. PSTN-to-IP > >direction), the > >>> calling > >>> number may be absent. The question is then how to express > >>originating > >>> trunk > >>> group. > >>> > >>> Thanks, > >>> > >>> Shan Lu > >>> > >>>> -----Original Message----- > >>>> From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] > >>>> On Behalf Of Jonathan Rosenberg > >>>> Sent: Tuesday, November 09, 2004 4:03 PM > >>>> To: list iptel > >>>> Subject: [Iptel] getting group consensus on moving forward > >>>> with our workitems > >>>> > >>>> > >>>> Folks, > >>>> > >>>> At the iptel meeting today, there was consensus in the room on > >>>> plans for > >>>> moving forward with various drafts. I'd like to verify that > >>>> consensus by > >>>> asking the list if folks are OK proceeding with the following: > >>>> > >>>> * Proceed to wglc on draft-ietf-iptel-tel-np once a revision > >>>> appears in > >>>> the archives > >>>> > >>>> * Proceed to wglc on > >>>> http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-grou > >>> p-02.txt > >>> immediately following the ietf > >>> > >>> * adopt > >>> http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi > >>> -00.txt > >>> as a work item of iptel > >>> > >>> * do not adopt > >>> > >>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstri > >ng-00.txt > >>> as a work item. The author will take it directly to IESG as an > >>> individual draft. > >>> > >>> * do not adopt the expired tel cpc draft > >>> > >(http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a > >>> work item. If folks have a problem that they believe is addressed by > >>> this work, please bring that forward in the next few weeks. > >>> > >>> * tgrep will go to IESG after a revision incorporating comments from > >>> Cullen and the pending comments from Jonathan > >>> > >>> Thanks, > >>> Jonathan R. > >>> -- > >>> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>> Director, Service Provider VoIP Architecture Parsippany, NJ > >>> 07054-2711 > >>> Cisco Systems > >>> jdrosen@cisco.com FAX: (973) 952-5050 > >>> http://www.jdrosen.net PHONE: (973) 952-5000 > >>> http://www.cisco.com > >>> > >>> > >>> _______________________________________________ > >>> Iptel mailing list > >>> Iptel@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/iptel > >>> > >>> > >>> _______________________________________________ > >>> Iptel mailing list > >>> Iptel@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/iptel > >>> > >>David R. Oran > >>Cisco Fellow > >>Cisco Systems > >>7 Ladyslipper Lane > >>Acton, MA 01720 USA > >>Tel: +1 978 264 2048 > >>Email: oran@cisco.com > >> > >> > >>_______________________________________________ > >>Iptel mailing list > >>Iptel@ietf.org > >>https://www1.ietf.org/mailman/listinfo/iptel > >> > > > > > >_______________________________________________ > >Iptel mailing list > >Iptel@ietf.org > >https://www1.ietf.org/mailman/listinfo/iptel > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 15 22:01:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11644 for ; Mon, 15 Nov 2004 22:01:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTtd1-000178-KA for iptel-web-archive@ietf.org; Mon, 15 Nov 2004 22:03:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtZt-0002AO-UY; Mon, 15 Nov 2004 22:00:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtZH-00021u-9x for iptel@megatron.ietf.org; Mon, 15 Nov 2004 21:59:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11559 for ; Mon, 15 Nov 2004 21:59:40 -0500 (EST) Received: from usjk1001.kddi.com ([211.4.169.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTtbM-000152-7p for iptel@ietf.org; Mon, 15 Nov 2004 22:01:54 -0500 Received: from usjk1035.kddi.com ([10.96.2.25]) by usjk1001.kddi.com with ESMTP id iAG2x6E15691; Tue, 16 Nov 2004 11:59:06 +0900 (JST) Received: from usjk1038 (localhost [127.0.0.1]) by usjk1035.kddi.com with SMTP id iAG2x5R29370; Tue, 16 Nov 2004 11:59:05 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041116025904.EACT24157.usjk1009.kddi.com@KDDI-0403PC0002>; Tue, 16 Nov 2004 11:59:04 +0900 To: jdrosen@cisco.com, iptel@ietf.org Subject: Comments on phone-context prameter (Re: [Iptel] getting group consensus on moving forward with our workitems) From: Takuya Sawada References: <4191309C.4050005@cisco.com> In-Reply-To: <4191309C.4050005@cisco.com> Message-Id: <200411161159.HAC46832.TBE-BUVBX@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Tue, 16 Nov 2004 11:59:05 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0411161159040000109958 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi, In the examples in trunk-group I-D, tgrp parameter appears before phone-context patrameter. This violates the rule of 2806bis, section 3; Each parameter name ("pname"), the ISDN subaddress, the 'extension' and the 'context' MUST NOT appear more than once. The 'isdn-subaddress' or 'extension' MUST appear first, if present, followed by the 'context' parameter, if present, followed by any other parameters in lexicographical order. This simplifies comparison when the "tel" URI is compared character-by-character, such as in SIP URIs [RFC3261]. So phone-context parameter MUST appear first, assuming that 2806bis will be approved as it is. Regards, Takuya Sawada > Folks, > > At the iptel meeting today, there was consensus in the room on plans for > moving forward with various drafts. I'd like to verify that consensus by > asking the list if folks are OK proceeding with the following: > > * Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears in > the archives > > * Proceed to wglc on > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt > immediately following the ietf > > * adopt > http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt > as a work item of iptel > > * do not adopt > http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt > as a work item. The author will take it directly to IESG as an > individual draft. > > * do not adopt the expired tel cpc draft > (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a > work item. If folks have a problem that they believe is addressed by > this work, please bring that forward in the next few weeks. > > * tgrep will go to IESG after a revision incorporating comments from > Cullen and the pending comments from Jonathan > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 00:43:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05660 for ; Tue, 16 Nov 2004 00:43:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTwAP-000438-Sl for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 00:46:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTw5t-00073J-DS; Tue, 16 Nov 2004 00:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTw3x-0006uI-Ur for iptel@megatron.ietf.org; Tue, 16 Nov 2004 00:39:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05342 for ; Tue, 16 Nov 2004 00:39:30 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTw65-0003xv-Oy for iptel@ietf.org; Tue, 16 Nov 2004 00:41:47 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 15 Nov 2004 21:53:55 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAG5ct3O023893; Mon, 15 Nov 2004 21:38:56 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT49621; Mon, 15 Nov 2004 21:38:57 -0800 (PST) Message-ID: <41999271.5030001@cisco.com> Date: Tue, 16 Nov 2004 00:38:57 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takuya Sawada Subject: Re: [Iptel] getting group consensus on moving forward with our workitems References: <4191309C.4050005@cisco.com> <200411151920.CJG55248.-EXBUBVBT@kddi.com> In-Reply-To: <200411151920.CJG55248.-EXBUBVBT@kddi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit inline. Takuya Sawada wrote: > Hi, > > I am not so happy to hear that cpc work will not move forward. > At least when interworking with ISUP or emulating the legacy PSTN, > cpc parameter seems to me to be useful. SIP-T exists for cases like this. For this work to be justified, there needs to be a reason for it on an IP network. > > For example, cpc=test paramter in P-Asserted-Identity header may > indicate that it is a test call so that it uses testing routing table > and is free of charge through the connection. There is value in doing test calls and diagnostics. However, the problem is broader than just copying the ISUP cpc=test parameter, and it needs to be looked at more holistically. > With cpc=priority, it can express it requires the call handling > with priority. (This should be done with R-P header, though) Priority call handling is also a more complicated subject. SIP already has a Priority header field for signifying priority to the called party, and work is underway in the conext of ieprep to prioritize calls during national emergencies. > With cpc=payphone, it may require to apply special charge rate, etc. We have RFC3840, which allows us to specify characteristics of the user agent. In any case, tying the presence of a capability/characteristic to a charging plan is a recipe for fraud. > > The scope of cpc work is probably limited to the legacy concept but > is useful in a certain situation. > Is it possible to move this forward to make an RFC as a working group > item, or as an individual submission? To date, the reasons brought forward for this draft were all in the category of "because isup has this". Generally speaking, that has not been sufficient justification for undertaking new work. Rather, specific problems need to be brought forward and a case made that existing solutions do not suffice. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 00:46:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05861 for ; Tue, 16 Nov 2004 00:46:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTwCx-00046O-5l for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 00:48:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTw9R-0007WZ-0r; Tue, 16 Nov 2004 00:45:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTw6C-00073W-C2 for iptel@megatron.ietf.org; Tue, 16 Nov 2004 00:41:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05444 for ; Tue, 16 Nov 2004 00:41:49 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTw8L-000409-7L for iptel@ietf.org; Tue, 16 Nov 2004 00:44:05 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 15 Nov 2004 21:56:15 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAG5fB3O024723; Mon, 15 Nov 2004 21:41:11 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT49700; Mon, 15 Nov 2004 21:41:13 -0800 (PST) Message-ID: <419992F9.5060801@cisco.com> Date: Tue, 16 Nov 2004 00:41:13 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu Subject: Re: Comments on Trunk Group ID and RE: [Iptel] getting group consensuson moving forward with our workitems References: <027701c4cb2a$34119910$eb00000a@SAJAK> In-Reply-To: <027701c4cb2a$34119910$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: "'list iptel'" , "'Vijay K. Gurbani'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Shan Lu wrote: > Vijay, > > Thanks for your response. > > As you are aware, there are two scenarios where the originating number may > be absent. PSTN may withhold the number or the PSTN-SIP gateway may not > entrust downstrem endpoints with the number in case of calling party > privacy. > > We have seen both cases and the need to know the incoming PSTN trunk group > when calling number is missing. In a lot applications, originating PSTN > trunk group info can be very useful for routing and revealing such info is > often not deemed to be a problem for privacy. Can you explain these use cases? Specifically, under what cases is the originating trunk group used for routing decisions on the SIP side of the gateway? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 00:47:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05903 for ; Tue, 16 Nov 2004 00:47:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTwEE-00047b-K1 for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 00:50:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTwAO-0007bI-Tb; Tue, 16 Nov 2004 00:46:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTw7R-0007Fm-DJ for iptel@megatron.ietf.org; Tue, 16 Nov 2004 00:43:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05561 for ; Tue, 16 Nov 2004 00:43:06 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTw9Z-00041P-At for iptel@ietf.org; Tue, 16 Nov 2004 00:45:22 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Nov 2004 21:55:32 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAG5gV3O025369 for ; Mon, 15 Nov 2004 21:42:32 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT49736; Mon, 15 Nov 2004 21:42:33 -0800 (PST) Message-ID: <41999349.70305@cisco.com> Date: Tue, 16 Nov 2004 00:42:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Iptel] Begin 2 week WGLC on trunk group ID X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Folks, This is to formally announce a 2 week working group last call on: http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt I'm glad to see we already have some discussion going on a comment made on this document. Please post any other comments on this draft during the last call period. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 02:30:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27277 for ; Tue, 16 Nov 2004 02:30:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTxpQ-00064v-Su for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 02:32:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTxiQ-0001zx-Jp; Tue, 16 Nov 2004 02:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTxhm-0001gW-Fr for iptel@megatron.ietf.org; Tue, 16 Nov 2004 02:24:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26373 for ; Tue, 16 Nov 2004 02:24:45 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTxjv-0005x1-Bf for iptel@ietf.org; Tue, 16 Nov 2004 02:27:00 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Nov 2004 23:37:10 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAG7Nhw0028416 for ; Mon, 15 Nov 2004 23:23:43 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAG7OVmf006564 for ; Mon, 15 Nov 2004 23:24:34 -0800 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <419992F9.5060801@cisco.com> References: <027701c4cb2a$34119910$eb00000a@SAJAK> <419992F9.5060801@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7A7FBF46-37A0-11D9-97C5-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: Comments on Trunk Group ID and RE: [Iptel] getting group consensuson moving forward with our workitems Date: Tue, 16 Nov 2004 02:23:57 -0500 To: "'list iptel'" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100589876.522640"; x:"432200"; a:"rsa-sha1"; b:"nofws:1736"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"lQShNDPOrVmqoCBfMJkMs56FIM1u+ib0vwzrxnS4WODa8r3XREPon74biJB+z" "khwJAVovNwRAPTKIF9HpnEOoiUzf1upk4vy9BpLPo6QU6BkWXTlO041fWfcCU" "PULS/HQIHkfNq/TmvQQEqHnZT0PafE3XnW1tebO2kMBFlaJx4="; c:"From: David R Oran "; c:"Subject: Re: Comments on Trunk Group ID and RE: [Iptel] getting group " "consensuson moving forward with our workitems"; c:"Date: Tue, 16 Nov 2004 02:23:57 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On Nov 16, 2004, at 12:41 AM, Jonathan Rosenberg wrote: > > > Shan Lu wrote: > >> Vijay, >> Thanks for your response. >> As you are aware, there are two scenarios where the originating >> number may >> be absent. PSTN may withhold the number or the PSTN-SIP gateway may >> not >> entrust downstrem endpoints with the number in case of calling party >> privacy. >> We have seen both cases and the need to know the incoming PSTN trunk >> group >> when calling number is missing. In a lot applications, originating >> PSTN >> trunk group info can be very useful for routing and revealing such >> info is >> often not deemed to be a problem for privacy. > > Can you explain these use cases? Specifically, under what cases is the > originating trunk group used for routing decisions on the SIP side of > the gateway? > Uh, trunk group routing? E.G. all calls coming in on trunk group 234156 (which happens to be from MCI in Alaska) and going to Tazmania get routed to C&W out trunk group 598275 (because I have a deal with C&W on calls to Tazmania this week). > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 09:47:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03658 for ; Tue, 16 Nov 2004 09:47:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4ed-00072r-Tf for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 09:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4Vb-0005rE-Ec; Tue, 16 Nov 2004 09:40:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4O2-0004Dr-0W for iptel@megatron.ietf.org; Tue, 16 Nov 2004 09:32:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02517 for ; Tue, 16 Nov 2004 09:32:48 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4QE-0006g4-OR for iptel@ietf.org; Tue, 16 Nov 2004 09:35:08 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iAGEWFdp028080; Tue, 16 Nov 2004 08:32:15 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iAGEWFs16863; Tue, 16 Nov 2004 08:32:15 -0600 (CST) Message-ID: <419A0F45.3050605@lucent.com> Date: Tue, 16 Nov 2004 08:31:33 -0600 From: "Vijay K. Gurbani" Organization: Wireless Research and Development/Internet Software and Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takuya Sawada Subject: Re: Comments on phone-context prameter (Re: [Iptel] getting group consensus on moving forward with our workitems) References: <4191309C.4050005@cisco.com> <200411161159.HAC46832.TBE-BUVBX@kddi.com> In-Reply-To: <200411161159.HAC46832.TBE-BUVBX@kddi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Takuya Sawada wrote: > Hi, > > In the examples in trunk-group I-D, tgrp parameter appears before > phone-context patrameter. This violates the rule of 2806bis, section 3; [...] > So phone-context parameter MUST appear first, assuming that > 2806bis will be approved as it is. Noted. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 09:55:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04194 for ; Tue, 16 Nov 2004 09:55:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4lq-0007Ee-Cs for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 09:57:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4Z8-0006Uq-9X; Tue, 16 Nov 2004 09:44:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4US-0005eh-Kv for iptel@megatron.ietf.org; Tue, 16 Nov 2004 09:39:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02983 for ; Tue, 16 Nov 2004 09:39:27 -0500 (EST) Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4We-0006pI-PY for iptel@ietf.org; Tue, 16 Nov 2004 09:41:46 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com with ESMTP id iAGEcal00953; Tue, 16 Nov 2004 23:38:36 +0900 (JST) Received: from usjk1038 (localhost [127.0.0.1]) by usjk1006.kddi.com with SMTP id iAGEca422500; Tue, 16 Nov 2004 23:38:36 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041116143834.HRTQ12322.usjk1010.kddi.com@KDDI-0403PC0002>; Tue, 16 Nov 2004 23:38:34 +0900 To: jdrosen@cisco.com, tu-sawada@kddi.com Subject: Re: [Iptel] getting group consensus on moving forward with ourworkitems From: Takuya Sawada References: <4191309C.4050005@cisco.com> <200411151920.CJG55248.-EXBUBVBT@kddi.com> <41999271.5030001@cisco.com> In-Reply-To: <41999271.5030001@cisco.com> Message-Id: <200411162338.IIB37339.BEXU-VBTB@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Tue, 16 Nov 2004 23:38:34 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0411162338330000107721 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Jonathan, I admit that you are saying right thing, but... comments inline. > inline. > > Takuya Sawada wrote: > > > Hi, > > > > I am not so happy to hear that cpc work will not move forward. > > At least when interworking with ISUP or emulating the legacy PSTN, > > cpc parameter seems to me to be useful. > > SIP-T exists for cases like this. For this work to be justified, there > needs to be a reason for it on an IP network. > For ISUP-SIP-ISUP interworking, I agree that SIP-T fits perfectly. But there are many cases that SIP-T, ISUP encapslation, can not apply. For SIP UA originating scenario, normally SIP UA can not build IAM message in INVITE request. > > > > For example, cpc=test paramter in P-Asserted-Identity header may > > indicate that it is a test call so that it uses testing routing table > > and is free of charge through the connection. > > There is value in doing test calls and diagnostics. However, the problem > is broader than just copying the ISUP cpc=test parameter, and it needs > to be looked at more holistically. > ISUP network can live with cpc=test for a long time :-) Yes, SIP can be more sophisticated. But the purpose of cpc=test is not diagnostics. It is not for checking what is wrong but just for making sure it is good before making the resources or configuration available to the ordinary usage. > > With cpc=priority, it can express it requires the call handling > > with priority. (This should be done with R-P header, though) > > Priority call handling is also a more complicated subject. SIP already > has a Priority header field for signifying priority to the called party, > and work is underway in the conext of ieprep to prioritize calls during > national emergencies. > Priority header can be applicable for that purpose. In table 3 of RFC 3261, "proxy" column of Priority header indicates "ar", add and read. I would be happier if it were "adr". Resource-Priority header will be a good candidate if approved. > > With cpc=payphone, it may require to apply special charge rate, etc. > > We have RFC3840, which allows us to specify characteristics of the user > agent. In any case, tying the presence of a capability/characteristic to > a charging plan is a recipe for fraud. > RFC 3840 define Contact header parameters. I assume cpc parameter to use with P-Asserted-Identity header. In that case cpc value is network asserted as it is in ISUP. For that purpose, defining new P- header or new P-Asserted-Identity header parameter may be appropriate, though... > > > > The scope of cpc work is probably limited to the legacy concept but > > is useful in a certain situation. > > Is it possible to move this forward to make an RFC as a working group > > item, or as an individual submission? > > To date, the reasons brought forward for this draft were all in the > category of "because isup has this". Generally speaking, that has not > been sufficient justification for undertaking new work. Rather, specific > problems need to be brought forward and a case made that existing > solutions do not suffice. > I can not disagree "because isup has this" is not sufficient. However, emulating ISUP with SIP is actually very important application of SIP, unfortunately. cpc parameter is the easiest way to emulate cpc parameter in ISUP. Probably the easiest way is not necessarily the best way. Umm.. does anyone have any other opinion? Regards, Takuya > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 10:11:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06152 for ; Tue, 16 Nov 2004 10:11:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU51T-0007gH-1V for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 10:13:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4t9-0003dx-8d; Tue, 16 Nov 2004 10:04:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4fp-0007Mt-1b for iptel@megatron.ietf.org; Tue, 16 Nov 2004 09:51:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03898 for ; Tue, 16 Nov 2004 09:51:11 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CU4hr-00076l-PJ for iptel@ietf.org; Tue, 16 Nov 2004 09:53:31 -0500 Received: (qmail 20856 invoked by uid 1014); 16 Nov 2004 14:50:30 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.033609 secs); 16 Nov 2004 14:50:30 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 16 Nov 2004 14:50:30 -0000 From: "Shan Lu" To: "'list iptel'" Subject: RE: Comments on Trunk Group ID and RE: [Iptel] gettinggroup consensuson moving forward with our workitems Date: Tue, 16 Nov 2004 09:51:51 -0500 Message-ID: <002d01c4cbeb$ceb99b40$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <7A7FBF46-37A0-11D9-97C5-000A95C73842@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >On Behalf Of David R Oran >Sent: Tuesday, November 16, 2004 2:24 AM >To: 'list iptel' >Subject: Re: Comments on Trunk Group ID and RE: [Iptel] >gettinggroup consensuson moving forward with our workitems > > >> >> Can you explain these use cases? Specifically, under what >cases is the >> originating trunk group used for routing decisions on the >SIP side of >> the gateway? >> >Uh, trunk group routing? E.G. all calls coming in on trunk >group 234156 >(which happens to be from MCI in Alaska) and going to Tazmania get >routed to C&W out trunk group 598275 (because I have a deal >with C&W on >calls to Tazmania this week). That's what I want to way. Regards, Shan Lu > >> -Jonathan R. >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >David R. Oran >Cisco Fellow >Cisco Systems >7 Ladyslipper Lane >Acton, MA 01720 USA >Tel: +1 978 264 2048 >Email: oran@cisco.com > > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 10:12:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06289 for ; Tue, 16 Nov 2004 10:12:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU52s-0007iF-TJ for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 10:15:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4tC-0003gY-FU; Tue, 16 Nov 2004 10:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4hq-0007bA-QF for iptel@megatron.ietf.org; Tue, 16 Nov 2004 09:53:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04069 for ; Tue, 16 Nov 2004 09:53:17 -0500 (EST) Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4k4-0007Af-KE for iptel@ietf.org; Tue, 16 Nov 2004 09:55:37 -0500 Received: from sonusms1.sonusnet.com (sonusms1 [10.128.32.93]) by revere.sonusnet.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iAGEql1l000145 for ; Tue, 16 Nov 2004 09:52:47 -0500 (EST) Received: from sonusmail03.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Tue, 16 Nov 2004 09:52:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] getting group consensus on moving forward with our workitems Date: Tue, 16 Nov 2004 09:52:46 -0500 Message-ID: Thread-Topic: [Iptel] getting group consensus on moving forward with our workitems Thread-Index: AcTK/a4mISMc/qrbSbSmFdHSJfiGlgA5s7Sw From: "Farahmand, Fardad" To: "Takuya Sawada" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Hi, I agree that the cpc draft is needed especially if one is not using = rfc3204. I would like to see this draft move forward as a WG item. I = also have a couple of suggestions for the author. First, it would be nice to see a clarification in this draft for cases = where the From header does not have user's identity and P-Asserted-ID = or P-Preferred-ID is present containing a tel-uri. =20 Second, include a complete list of cpc values. =20 Thanks, Fardad =20 -----Original Message----- From: Takuya Sawada [mailto:tu-sawada@kddi.com] Sent: Monday, November 15, 2004 5:20 AM To: jdrosen@cisco.com; iptel@ietf.org Subject: Re: [Iptel] getting group consensus on moving forward with our workitems Hi, I am not so happy to hear that cpc work will not move forward. At least when interworking with ISUP or emulating the legacy PSTN, cpc parameter seems to me to be useful. For example, cpc=3Dtest paramter in P-Asserted-Identity header may indicate that it is a test call so that it uses testing routing table and is free of charge through the connection. With cpc=3Dpriority, it can express it requires the call handling with priority. (This should be done with R-P header, though) With cpc=3Dpayphone, it may require to apply special charge rate, etc. The scope of cpc work is probably limited to the legacy concept but is useful in a certain situation. Is it possible to move this forward to make an RFC as a working group item, or as an individual submission? Regards, Takuya > Folks, >=20 > At the iptel meeting today, there was consensus in the room on plans = for=20 > moving forward with various drafts. I'd like to verify that consensus = by=20 > asking the list if folks are OK proceeding with the following: >=20 > * Proceed to wglc on draft-ietf-iptel-tel-np once a revision appears = in=20 > the archives >=20 > * Proceed to wglc on=20 > = http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt=20 > immediately following the ietf >=20 > * adopt=20 > = http://www.ietf.org/internet-drafts/draft-stastny-iptel-tel-enumdi-00.txt= =20 > as a work item of iptel >=20 > * do not adopt=20 > = http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-00.txt=20 > as a work item. The author will take it directly to IESG as an=20 > individual draft. >=20 > * do not adopt the expired tel cpc draft=20 > (http://www.watersprings.org/pub/id/draft-mahy-iptel-cpc-01.txt) as a=20 > work item. If folks have a problem that they believe is addressed by=20 > this work, please bring that forward in the next few weeks. >=20 > * tgrep will go to IESG after a revision incorporating comments from=20 > Cullen and the pending comments from Jonathan >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ = 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi,=20 Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 10:36:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10626 for ; Tue, 16 Nov 2004 10:36:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5PW-0008KN-A6 for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 10:38:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU59Z-0001zP-N4; Tue, 16 Nov 2004 10:21:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU52l-0007zP-E9 for iptel@megatron.ietf.org; Tue, 16 Nov 2004 10:14:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06587 for ; Tue, 16 Nov 2004 10:14:53 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU54y-0007kS-Uo for iptel@ietf.org; Tue, 16 Nov 2004 10:17:13 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAGFDp8j014300; Tue, 16 Nov 2004 09:14:11 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iAGFDps26922; Tue, 16 Nov 2004 09:13:51 -0600 (CST) Message-ID: <419A1905.4010507@lucent.com> Date: Tue, 16 Nov 2004 09:13:09 -0600 From: "Vijay K. Gurbani" Organization: Wireless Research and Development/Internet Software and Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu References: <027701c4cb2a$34119910$eb00000a@SAJAK> In-Reply-To: <027701c4cb2a$34119910$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: "'list iptel'" Subject: [Iptel] Originating trunk group without calling number (Was [Re: Comments on Trunk Group ID]) X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Shan Lu wrote: > Vijay, [...] > I am happy with the draft as far as destination TG is concerned. > But I don't think it should prescribe a formula for originating > TG whose validity is sometimes questionable. I think you mean above that the validity of the calling party number is questionable, not the trunk group's? OK, so given the ensuing discussion on the appropriateness of carrying a trunk group even if the calling party number is not available, it would seem that there are three ways to move forward. I would like to reach consensus on one of them. Let me list them and provide some pros and cons. (1) As suggested by Shan Lu, using a "tel:-;tgrp=foo" in the Contact URI. (2) In the Contact, use a tel URI of the form: "tel:0000;tgrp=foo;phone-context=example.com" (3) In the Contact, use a SIP URI of the form: "sip:anonymous;tgrp=foo;phone-context=example.com@example.com" For (1), I wonder if the intent of the author of rfc2806-bis was indeed to sanction such use. While the ABNF may allow it implicitly, should we endorse such a usage? I am sure with enough ingenuity, production rules of many ABNFs can yield pretty interesting outcomes. Maybe the WG can decide if the use of tel URI in this form is okay. In (2), the "0000" in the Contact URI serves as a filler. The proxy receiving a request from its upstream gateway with such a filler will know that an calling party number was not provided. Note that this case is distinct from a "0000" in the R-URI of a request arriving from the PSTN, which could signify a valid number in the domain of the proxy handling the request. (3) uses a SIP URI in the Contact header, avoiding the ambiguities associated with (1) and (2). My preference would be (3). Any feedback and discussion most welcome. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 12:30:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22189 for ; Tue, 16 Nov 2004 12:30:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7CO-0002ki-1K for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 12:33:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU753-0006ip-2T; Tue, 16 Nov 2004 12:25:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6pg-0002AW-OZ for iptel@megatron.ietf.org; Tue, 16 Nov 2004 12:09:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20171 for ; Tue, 16 Nov 2004 12:09:30 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CU6ru-0002CA-TD for iptel@ietf.org; Tue, 16 Nov 2004 12:11:52 -0500 Received: (qmail 46216 invoked by uid 1014); 16 Nov 2004 17:09:00 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.033687 secs); 16 Nov 2004 17:09:00 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 16 Nov 2004 17:09:00 -0000 From: "Shan Lu" To: Subject: RE: [Iptel] getting group consensus on moving forward withourworkitems Date: Tue, 16 Nov 2004 12:10:21 -0500 Message-ID: <004e01c4cbff$27c97670$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <200411162338.IIB37339.BEXU-VBTB@kddi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Hi all, I support progressing the CPC draft as WG item. Comments inline. Regards, Shan Lu >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] >On Behalf Of Takuya Sawada >Sent: Tuesday, November 16, 2004 9:39 AM >To: jdrosen@cisco.com; tu-sawada@kddi.com >Cc: iptel@ietf.org >Subject: Re: [Iptel] getting group consensus on moving forward >withourworkitems > > >Jonathan, > >I admit that you are saying right thing, but... > >comments inline. > >> inline. >> >> Takuya Sawada wrote: >> >> > Hi, >> > >> > I am not so happy to hear that cpc work will not move forward. >> > At least when interworking with ISUP or emulating the legacy PSTN, >> > cpc parameter seems to me to be useful. >> >> SIP-T exists for cases like this. For this work to be >justified, there >> needs to be a reason for it on an IP network. >> >For ISUP-SIP-ISUP interworking, I agree that SIP-T fits perfectly. >But there are many cases that SIP-T, ISUP encapslation, can not apply. >For SIP UA originating scenario, normally SIP UA can not build IAM >message in INVITE request. > One such case would be a feature server (SBC, for example) managing end users (user agents). But SIP/ISUP interworking is performed by a completely separated entitiy. This interworking GW is not aware of end user profiles. It will be useful for the feature server to inform the gateway a calling UA's CPC so that IAM can be correctly constructed. Obviously this still falls under "because ISUP has it" category. But at least it provides an interworking motivation. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 16 15:26:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09171 for ; Tue, 16 Nov 2004 15:26:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9wm-000778-6f for iptel-web-archive@ietf.org; Tue, 16 Nov 2004 15:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9rs-00028z-Hr; Tue, 16 Nov 2004 15:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9jw-0004yB-IE for iptel@megatron.ietf.org; Tue, 16 Nov 2004 15:15:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07874 for ; Tue, 16 Nov 2004 15:15:47 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9mC-0006q0-AV for iptel@ietf.org; Tue, 16 Nov 2004 15:18:09 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 16 Nov 2004 12:15:55 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAGKFEVx015913; Tue, 16 Nov 2004 12:15:14 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT88755; Tue, 16 Nov 2004 12:15:13 -0800 (PST) Message-ID: <419A5FD0.6030407@cisco.com> Date: Tue, 16 Nov 2004 15:15:12 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu Subject: Re: [Iptel] getting group consensus on moving forward withourworkitems References: <004e01c4cbff$27c97670$eb00000a@SAJAK> In-Reply-To: <004e01c4cbff$27c97670$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit inline. Shan Lu wrote: >>For ISUP-SIP-ISUP interworking, I agree that SIP-T fits perfectly. >>But there are many cases that SIP-T, ISUP encapslation, can not apply. >>For SIP UA originating scenario, normally SIP UA can not build IAM >>message in INVITE request. >> > > > One such case would be a feature server (SBC, for example) managing end > users (user agents). But SIP/ISUP interworking is performed by a completely > separated entitiy. This interworking GW is not aware of end user profiles. > It will be useful for the feature server to inform the gateway a calling > UA's CPC so that IAM can be correctly constructed. Obviously this still > falls under "because ISUP has it" category. But at least it provides an > interworking motivation. My point was, in all such cases that I have heard, there were other ways to indicate the desired information in a manner appropriate for SIP, and then these could be converted to their appropriate ISUP versions at a gateway. For example, we have a mechanism for defining the characteristics of a UA (rfc3840) which can be used to signal things like the fact that this is a prison phone. Seems like such a characteristic does not depend on the fact that the endpoint is represented with a tel URI, and might be useful for SIP to SIP calls. This means that defining a tel URI parameter to map 1-1 with ISUP equivalents is the wrong way to do this. In SIP, we have not elected to simply redefine every ISUP parameter into SIP. Rather, we defined things appropriately for a SIP network, and then specified how they get converted at a gateway. Why should CPC be different? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Nov 17 03:10:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25436 for ; Wed, 17 Nov 2004 03:10:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUKvq-0001oJ-3W for iptel-web-archive@ietf.org; Wed, 17 Nov 2004 03:12:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKqW-0006IH-Vh; Wed, 17 Nov 2004 03:07:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKjM-0004tP-Fv for iptel@megatron.ietf.org; Wed, 17 Nov 2004 02:59:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24297 for ; Wed, 17 Nov 2004 02:59:54 -0500 (EST) Received: from usjk1001.kddi.com ([211.4.169.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUKlZ-0001ZH-4T for iptel@ietf.org; Wed, 17 Nov 2004 03:02:23 -0500 Received: from usjk1035.kddi.com ([10.96.2.25]) by usjk1001.kddi.com with ESMTP id iAH7xDE11203; Wed, 17 Nov 2004 16:59:13 +0900 (JST) Received: from usjk1039 (localhost [127.0.0.1]) by usjk1035.kddi.com with SMTP id iAH7xCR00036; Wed, 17 Nov 2004 16:59:12 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041117075910.LXWD12322.usjk1010.kddi.com@KDDI-0403PC0002>; Wed, 17 Nov 2004 16:59:10 +0900 To: vkg@lucent.com, shanlu@sentito.com Subject: Re: [Iptel] Originating trunk group without calling number (Was [Re:Comments on Trunk Group ID]) From: Takuya Sawada References: <027701c4cb2a$34119910$eb00000a@SAJAK> <419A1905.4010507@lucent.com> In-Reply-To: <419A1905.4010507@lucent.com> Message-Id: <200411171659.AHE14334.BBVX-ETUB@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Wed, 17 Nov 2004 16:59:10 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0411171659100000218455 X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Hi, I think only (3) conforms to both 2806bis and RFC 3261. But (3) is not tel URI at all. It is just the convention of the SIP URI's user part usage. Comments inline. > Shan Lu wrote: > > > Vijay, > [...] > > I am happy with the draft as far as destination TG is concerned. > > But I don't think it should prescribe a formula for originating > > TG whose validity is sometimes questionable. > > I think you mean above that the validity of the calling party > number is questionable, not the trunk group's? > > OK, so given the ensuing discussion on the appropriateness of > carrying a trunk group even if the calling party number is not > available, it would seem that there are three ways to move > forward. > > I would like to reach consensus on one of them. Let me list > them and provide some pros and cons. > > (1) As suggested by Shan Lu, using a "tel:-;tgrp=foo" in > the Contact URI. > ABNF in 2806bis-09 explicitly does not allow the form above. telephone-uri = "tel:" telephone-subscriber telephone-subscriber = global-number / local-number global-number = global-number-digits *par local-number = local-number-digits *par context *par context = ";phone-context=" descriptor global-number-digits = "+" 1*phonedigit > (2) In the Contact, use a tel URI of the form: > "tel:0000;tgrp=foo;phone-context=example.com" > Contact header MUST be a SIP or SIPS URI according to RFC 3261, section 8.1.18. TEL URI is not allowed to appear in Contact header in INVITE request. > (3) In the Contact, use a SIP URI of the form: > "sip:anonymous;tgrp=foo;phone-context=example.com@example.com" > This is legal but not related to tel URI... Probably we can live with this. But we may have another choice. (4) sip:0000;tgrp=foo;phone-context=example.com@example.com" I do not have any preference between (3) and (4). Regards, Takuya > For (1), I wonder if the intent of the author of rfc2806-bis > was indeed to sanction such use. While the ABNF may allow > it implicitly, should we endorse such a usage? I am sure > with enough ingenuity, production rules of many ABNFs can > yield pretty interesting outcomes. > > Maybe the WG can decide if the use of tel URI in this form > is okay. > > In (2), the "0000" in the Contact URI serves as a filler. > The proxy receiving a request from its upstream gateway > with such a filler will know that an calling party number > was not provided. > > Note that this case is distinct from a "0000" in the > R-URI of a request arriving from the PSTN, which could > signify a valid number in the domain of the proxy handling > the request. > > (3) uses a SIP URI in the Contact header, avoiding the > ambiguities associated with (1) and (2). > > My preference would be (3). > > Any feedback and discussion most welcome. > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Nov 17 10:13:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06733 for ; Wed, 17 Nov 2004 10:13:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CURXS-0003Be-Jz for iptel-web-archive@ietf.org; Wed, 17 Nov 2004 10:16:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUROB-0004Xk-AG; Wed, 17 Nov 2004 10:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CURJc-0001xn-10 for iptel@megatron.ietf.org; Wed, 17 Nov 2004 10:01:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05297 for ; Wed, 17 Nov 2004 10:01:45 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CURLs-0002wE-Fk for iptel@ietf.org; Wed, 17 Nov 2004 10:04:18 -0500 Received: (qmail 47865 invoked by uid 1014); 17 Nov 2004 15:01:06 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.038138 secs); 17 Nov 2004 15:01:06 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 17 Nov 2004 15:01:06 -0000 From: "Shan Lu" To: "'Takuya Sawada'" , Subject: RE: [Iptel] Originating trunk group without calling number (Was[Re:Comments on Trunk Group ID]) Date: Wed, 17 Nov 2004 10:02:27 -0500 Message-ID: <009f01c4ccb6$73d7c050$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <200411171659.AHE14334.BBVX-ETUB@kddi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Takuya and Vijay, I believe there are two steps here. The first one is to come up with a = valid tel-uri format. The second step is to put it in a SIP header and most = likely convert it to SIP URI. WRT step 1, we have two proposals: A) tel:-;phone-context=3Dlocal;tgrp=3Dfoo B) tel:0000;phone-context=3Dlocal;tgrp=3Dfoo Takuya correctly pointed out that "phone-context" must be present in = both formats.=20 Assuming Proposal A passes 2806bis validity test, I definitely favor it. = My concern w/ B is the potential confusion that "0000" (or any other digit string) may create in a local numbering plan. Regards, Shan Lu >-----Original Message----- >From: iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org]=20 >On Behalf Of Takuya Sawada >Sent: Wednesday, November 17, 2004 2:59 AM >To: vkg@lucent.com; shanlu@sentito.com >Cc: iptel@ietf.org >Subject: Re: [Iptel] Originating trunk group without calling=20 >number (Was[Re:Comments on Trunk Group ID]) > > >Hi, > >I think only (3) conforms to both 2806bis and RFC 3261. >But (3) is not tel URI at all. It is just the convention of the >SIP URI's user part usage. > >Comments inline. > >> Shan Lu wrote: >>=20 >> > Vijay, >> [...] >> > I am happy with the draft as far as destination TG is concerned.=20 >> > But I don't think it should prescribe a formula for originating=20 >> > TG whose validity is sometimes questionable. >>=20 >> I think you mean above that the validity of the calling party >> number is questionable, not the trunk group's? >>=20 >> OK, so given the ensuing discussion on the appropriateness of >> carrying a trunk group even if the calling party number is not >> available, it would seem that there are three ways to move >> forward. >>=20 >> I would like to reach consensus on one of them. Let me list >> them and provide some pros and cons. >>=20 >> (1) As suggested by Shan Lu, using a "tel:-;tgrp=3Dfoo" in >> the Contact URI. >>=20 >ABNF in 2806bis-09 explicitly does not allow the form above. > > telephone-uri =3D "tel:" telephone-subscriber > telephone-subscriber =3D global-number / local-number > global-number =3D global-number-digits *par > local-number =3D local-number-digits *par context *par > context =3D ";phone-context=3D" descriptor > global-number-digits =3D "+" 1*phonedigit > >> (2) In the Contact, use a tel URI of the form: >> "tel:0000;tgrp=3Dfoo;phone-context=3Dexample.com" >>=20 >Contact header MUST be a SIP or SIPS URI according to RFC 3261, >section 8.1.18. >TEL URI is not allowed to appear in Contact header in INVITE request. > >> (3) In the Contact, use a SIP URI of the form: >> = "sip:anonymous;tgrp=3Dfoo;phone-context=3Dexample.com@example.com" >>=20 >This is legal but not related to tel URI... >Probably we can live with this. >But we may have another choice. > >(4) >sip:0000;tgrp=3Dfoo;phone-context=3Dexample.com@example.com" > >I do not have any preference between (3) and (4). > >Regards, >Takuya > >> For (1), I wonder if the intent of the author of rfc2806-bis >> was indeed to sanction such use. While the ABNF may allow >> it implicitly, should we endorse such a usage? I am sure >> with enough ingenuity, production rules of many ABNFs can >> yield pretty interesting outcomes. >>=20 >> Maybe the WG can decide if the use of tel URI in this form >> is okay. >>=20 >> In (2), the "0000" in the Contact URI serves as a filler. >> The proxy receiving a request from its upstream gateway >> with such a filler will know that an calling party number >> was not provided. >>=20 >> Note that this case is distinct from a "0000" in the >> R-URI of a request arriving from the PSTN, which could >> signify a valid number in the domain of the proxy handling >> the request. >>=20 >> (3) uses a SIP URI in the Contact header, avoiding the >> ambiguities associated with (1) and (2). >>=20 >> My preference would be (3). >>=20 >> Any feedback and discussion most welcome. >>=20 >> Thanks, >>=20 >> - vijay >> --=20 >> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} >> Wireless Networks Group/Internet Software and Services >> Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane,=20 >Rm 6G-440 >> Naperville, Illinois 60566 Voice: +1 630 224 0216 >>=20 >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel > > >-------- >Takuya Sawada >KDDI Corporation (KDDI) >Garden Air Tower, 3-10-10, Iidabashi,=20 >Chiyoda-ku, Tokyo 102-8460, Japan >Tel: +81-3-6678-2997 >Fax: +81-3-6678-0286 >tu-sawada@kddi.com > >_______________________________________________ >Iptel mailing list >Iptel@ietf.org >https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Nov 18 12:35:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14676 for ; Thu, 18 Nov 2004 12:35:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqF5-0006sK-GE for iptel-web-archive@ietf.org; Thu, 18 Nov 2004 12:38:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUq27-000461-Pq; Thu, 18 Nov 2004 12:25:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUpog-0006Il-RP for iptel@megatron.ietf.org; Thu, 18 Nov 2004 12:11:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12543 for ; Thu, 18 Nov 2004 12:11:28 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUprM-0006FN-9t for iptel@ietf.org; Thu, 18 Nov 2004 12:14:16 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAIHAvjt005624; Thu, 18 Nov 2004 11:10:58 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iAIHAuJ28144; Thu, 18 Nov 2004 11:10:56 -0600 (CST) Message-ID: <419CD7A0.5070200@lucent.com> Date: Thu, 18 Nov 2004 11:10:56 -0600 From: "Vijay K. Gurbani" Organization: Wireless Research and Development/Internet Software and Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu Subject: Re: [Iptel] Originating trunk group without calling number (Was[Re:Comments on Trunk Group ID]) References: <009f01c4ccb6$73d7c050$eb00000a@SAJAK> In-Reply-To: <009f01c4ccb6$73d7c050$eb00000a@SAJAK> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, "'Takuya Sawada'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Shan Lu wrote: > Takuya and Vijay, > > I believe there are two steps here. The first one is to come up > with a valid tel-uri format. The second step is to put it in > a SIP header and most likely convert it to SIP URI. > > WRT step 1, we have two proposals: > > A) tel:-;phone-context=local;tgrp=foo > B) tel:0000;phone-context=local;tgrp=foo > Assuming Proposal A passes 2806bis validity test, I definitely > favor it. I don't think A is a valid tel URI as per the production rules of rfc2806bis. Please double-check, but I do not think it is. > My concern w/ B is the potential confusion that "0000" (or > any other digit string) may create in a local numbering plan. Yes, I agree. I had pointed that out in my original email as a disadvantage. So, that leaves the following two choices (one from my original email and the second one from Takyua's follow-up): 1) sip:anonymous;tgrp=foo;phone-context=example.com@example.com 2) sip:0000;tgrp=foo;phone-context=example.com@example.com (2) still suffers from the ambiguity problem...so, I still prefer (1). The ambiguity in (2) is manageable since it is the proxy that will be sending this URI in subsequent requests to the gateway. The gateway can associate a sip:0000 to mean that the incoming number was absent when the call was initially setup. Of course, this is brittle and assumes some handshaking between the gateway and the proxy (what if they want to use sip:9999 instead?). That is why I favor (1). However, I do not have religious feelings about this, so I am happy with whatever the WG decides. Comments....? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Nov 18 16:05:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12746 for ; Thu, 18 Nov 2004 16:05:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtVf-0005qo-IH for iptel-web-archive@ietf.org; Thu, 18 Nov 2004 16:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsoH-0004Jn-6M; Thu, 18 Nov 2004 15:23:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUsgY-00075K-Bm; Thu, 18 Nov 2004 15:15:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01445; Thu, 18 Nov 2004 15:15:16 -0500 (EST) Message-Id: <200411182015.PAA01445@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 18 Nov 2004 15:15:15 -0500 Cc: iptel@ietf.org Subject: [Iptel] I-D ACTION:draft-ietf-iptel-tel-np-03.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --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 : New Parameters for the 'tel' URI to Support Number Portability Author(s) : J. Yu Filename : draft-ietf-iptel-tel-np-03.txt Pages : 12 Date : 2004-11-18 This document defines several new parameters in the 'tel' Uniform Resource Identifier (URI) to support number portability (NP) for geographical telephone numbers and freephone numbers. The 'rn' parameter carries the routing number for a ported geographical telephone number. The presence of the 'npdi' parameter indicates that NP database dip has been performed on a geographical telephone number. The 'cic' parameter identifies the freephone service provider for a freephone number. The 'rn-context' and 'cic-context' parameters describe the 'rn' and 'cic' parameters respectively when the 'rn' and 'cic' parameters contain information in the 'local' format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-tel-np-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-iptel-tel-np-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-18141946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-tel-np-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-tel-np-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-18141946.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --NextPart-- From iptel-bounces@ietf.org Fri Nov 19 07:59:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27061 for ; Fri, 19 Nov 2004 07:59:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV8PC-0003am-9K for iptel-web-archive@ietf.org; Fri, 19 Nov 2004 08:02:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV8LB-0003gh-RT; Fri, 19 Nov 2004 07:58:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV8Bj-0001mn-C1 for iptel@megatron.ietf.org; Fri, 19 Nov 2004 07:48:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26066 for ; Fri, 19 Nov 2004 07:48:30 -0500 (EST) Received: from usjk1002.kddi.com ([211.4.169.18]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV8EO-0003B4-C1 for iptel@ietf.org; Fri, 19 Nov 2004 07:51:27 -0500 Received: from usjk1006.kddi.com (usjk1006 [10.96.2.3]) by usjk1002.kddi.com with ESMTP id iAJClkl10214; Fri, 19 Nov 2004 21:47:46 +0900 (JST) Received: from usjk1037 (localhost [127.0.0.1]) by usjk1006.kddi.com with SMTP id iAJClj412869; Fri, 19 Nov 2004 21:47:45 +0900 (JST) Received: from KDDI-0403PC0002 ([10.100.94.32]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20041119124741.ZQUS12322.usjk1010.kddi.com@KDDI-0403PC0002>; Fri, 19 Nov 2004 21:47:41 +0900 To: vkg@lucent.com, shanlu@sentito.com Subject: Re: [Iptel] Originating trunk group without calling number(Was[Re:Comments on Trunk Group ID]) From: Takuya Sawada References: <009f01c4ccb6$73d7c050$eb00000a@SAJAK> <419CD7A0.5070200@lucent.com> In-Reply-To: <419CD7A0.5070200@lucent.com> Message-Id: <200411192147.HJG85313.VBTBUEB-X@kddi.com> X-Mailer: Winbiff [Version 2.42 PL2] X-Accept-Language: ja,en Date: Fri, 19 Nov 2004 21:47:41 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-WAuditID: 0411192147410000024748 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: iptel@ietf.org, tu-sawada@kddi.com X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Hi, In 2806bis-09 local-number = local-number-digits *par context *par local-number-digits = 1*phonedigit-hex phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] I think "tel:-;phone-context=local;tgrp=foo" is sytactically OK. (I don't know why visual-separator is inside square blackets.) Anyway, I think now we reach the consensus to use the following format; sip:local-number-digits;phone-context=domain;tgrp=foo@domain First, I want to ask whether we should a) leave this as the matter of the adminstrative domain indicated by phone-context, or b) define global unique format for void-number. If a) no further question is needed. If b), then, I want to ask what the unique format should be; b-1) fixed non-number format which is not compliant to "local-number-digits" to avoid conflict (like "anonymous"), b-2) fixed visual-separator only format to be syntacticaly compliant to "local-number-digits" and to avoid conflict (like "-"), b-3) fixed number format to "fully" compliant to the intended format of "local-number-digits", but taking the risk of conflict (like "0000"), b-4) fixed non-DIGIT format to reduce the risk of conflict comparing b-3) (like "####"), b-5) any visual-separator only string which can be interpreted that any valid digits is not included (like "-", ".", "----", and so on), b-6) void. (like sip:;phone-context=domain;tgrp=foo@domain) b-6) is not compliant to ABNF in 2806bis unless 2806bis is modified to allow it as follows; local-number-digits = *phonedigit-hex I don't know if it is good idea to modify, though. (maybe ugly) I do not have any strong preference. Just pick one of these. Ummm.. a) or b-2)/b-5)? Comments? Regards, Takuya > Shan Lu wrote: > > > Takuya and Vijay, > > > > I believe there are two steps here. The first one is to come up > > with a valid tel-uri format. The second step is to put it in > > a SIP header and most likely convert it to SIP URI. > > > > WRT step 1, we have two proposals: > > > > A) tel:-;phone-context=local;tgrp=foo > > B) tel:0000;phone-context=local;tgrp=foo > > Assuming Proposal A passes 2806bis validity test, I definitely > > favor it. > > I don't think A is a valid tel URI as per the production > rules of rfc2806bis. Please double-check, but I do not > think it is. > > > My concern w/ B is the potential confusion that "0000" (or > > any other digit string) may create in a local numbering plan. > > Yes, I agree. I had pointed that out in my original email > as a disadvantage. > > So, that leaves the following two choices (one from my original > email and the second one from Takyua's follow-up): > > 1) sip:anonymous;tgrp=foo;phone-context=example.com@example.com > 2) sip:0000;tgrp=foo;phone-context=example.com@example.com > > (2) still suffers from the ambiguity problem...so, I still > prefer (1). > > The ambiguity in (2) is manageable since it is the proxy that > will be sending this URI in subsequent requests to the > gateway. The gateway can associate a sip:0000 to mean that > the incoming number was absent when the call was initially > setup. Of course, this is brittle and assumes some handshaking > between the gateway and the proxy (what if they want to use > sip:9999 instead?). > > That is why I favor (1). However, I do not have religious > feelings about this, so I am happy with whatever the WG > decides. > > Comments....? > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Wireless Networks Group/Internet Software and Services > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0286 tu-sawada@kddi.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 22 13:49:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01885 for ; Mon, 22 Nov 2004 13:49:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJJZ-0002Wm-TZ for iptel-web-archive@ietf.org; Mon, 22 Nov 2004 13:53:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJAK-0004XQ-Il; Mon, 22 Nov 2004 13:43:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJ0W-0002yP-I7 for iptel@megatron.ietf.org; Mon, 22 Nov 2004 13:33:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00670 for ; Mon, 22 Nov 2004 13:33:47 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJ41-00010e-Jn for iptel@ietf.org; Mon, 22 Nov 2004 13:37:25 -0500 Received: from RSHOCKEY-LTXP.shockey.us (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id iAMIXEFW006041 for ; Mon, 22 Nov 2004 10:33:16 -0800 Message-Id: <6.1.2.0.2.20041122133049.04c477a0@sb7.songbird.com> X-Sender: richard@sb7.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 22 Nov 2004 13:31:34 -0500 To: iptel@ietf.org From: Richard Shockey Subject: Re: [Iptel] I-D ACTION:draft-ietf-iptel-tel-np-03.txt In-Reply-To: <200411182015.PAA01445@ietf.org> References: <200411182015.PAA01445@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.8 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.8 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa At 03:15 PM 11/18/2004, Internet-Drafts@ietf.org wrote: I think there was consensus at 61 that this could go to last call. >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 : New Parameters for the 'tel' URI to Support > Number Portability > Author(s) : J. Yu > Filename : draft-ietf-iptel-tel-np-03.txt > Pages : 12 > Date : 2004-11-18 > >This document defines several new parameters in the 'tel' Uniform > Resource Identifier (URI) to support number portability (NP) for > geographical telephone numbers and freephone numbers. The 'rn' > parameter carries the routing number for a ported geographical > telephone number. The presence of the 'npdi' parameter indicates > that NP database dip has been performed on a geographical telephone > number. The 'cic' parameter identifies the freephone service > provider for a freephone number. The 'rn-context' and 'cic-context' > parameters describe the 'rn' and 'cic' parameters respectively when > the 'rn' and 'cic' parameters contain information in the 'local' > format. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Nov 24 01:03:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18174 for ; Wed, 24 Nov 2004 01:03:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWqJR-00010N-OO for iptel-web-archive@ietf.org; Wed, 24 Nov 2004 01:07:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqE8-0008St-38; Wed, 24 Nov 2004 01:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWqB9-0007fw-CI for iptel@megatron.ietf.org; Wed, 24 Nov 2004 00:58:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17849 for ; Wed, 24 Nov 2004 00:58:55 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWqEw-0000Fr-LS for iptel@ietf.org; Wed, 24 Nov 2004 01:02:55 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2004 23:04:17 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAO5wM9N010675 for ; Tue, 23 Nov 2004 21:58:22 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn1-542.cisco.com [10.21.98.30]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFY15463; Tue, 23 Nov 2004 21:58:24 -0800 (PST) Message-ID: <41A422FF.8040402@cisco.com> Date: Wed, 24 Nov 2004 00:58:23 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Iptel] Begin WGLC for draft-ietf-iptel-tel-np-03 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit The draft can now be found here: http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-np-03.txt The WGLC will last two weeks. Please send comments either to the list or to the authors if the comments are minor. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 29 13:56:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19511 for ; Mon, 29 Nov 2004 13:56:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqmb-0000Lz-Cf for iptel-web-archive@ietf.org; Mon, 29 Nov 2004 14:01:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqet-00021a-Uf; Mon, 29 Nov 2004 13:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqcj-0001fz-Dd for iptel@megatron.ietf.org; Mon, 29 Nov 2004 13:51:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19009 for ; Mon, 29 Nov 2004 13:51:44 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqhg-0000Dm-Jd for iptel@ietf.org; Mon, 29 Nov 2004 13:56:53 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iATIpAUQ004426; Mon, 29 Nov 2004 12:51:10 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iATIp5X15259; Mon, 29 Nov 2004 12:51:10 -0600 (CST) Message-ID: <41AB6F99.1060005@lucent.com> Date: Mon, 29 Nov 2004 12:51:05 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu , "'Takuya Sawada'" Subject: Re: [Iptel] Originating trunk group without calling number(Was[Re:Comments on Trunk Group ID]) References: <016501c4ce46$0172a660$eb00000a@SAJAK> In-Reply-To: <016501c4ce46$0172a660$eb00000a@SAJAK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: IETF IPTEL WG X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Continuing our leftover discussion on representing the trunk group if the calling party was not present in an incoming session setup request...a question for the IPTEL co-chairs is embedded in the writeup below. With the subsequent confirmation from rfc2806bis author regarding the inappropriateness of the following tel URI (despite it being syntactically correct): tel:-;phone-context=example.com;tgrp=foo I would like to revisit my earlier suggestion to use the following URI when the calling party is not known: sip:anonymous;phone-context=example.com;tgrp=foo@example.com If we go this route, Shan Lu raises good questions on the choice of this URI. But I believe that these questions have answers that fit within the current usage of SIP. Namely, > I am a little confused about this. The draft started by defining a > tel-uri extension "tgrp" and now we seemed to end up reserving a > section of userinfo space in sip uri. My other concern with reserving > sip uri userinfo space is that we may need SIP WG blessing, which > will further delay the draft, if we can get the nod at all. I don't think that this is insurmountable. Note that RFC3261 uses the display name "Anonymous" and a URI of anonymous@anonymous.invalid for privacy reasons. While I agree that the use of such display names and URI is not normative in RFC3261, the inherent understanding is that this use of 'anonymous' is okay (at least, that is my read of the specification). So, I do not believe that we will need to seek the blessing of the SIP WG to use the username 'anonymous'. IPTEL co-chairs can provide further guidance if my understanding is flawed on this count. > Also, a format that stays completely within tel-uri can be used in > applications other than SIP. I believe that using the anonymous SIP URI in this manner is a way to plug a corner case that you have identified; namely that the calling party's number may be absent in the ISUP request coming into a gateway. This is an exception; the normal case will be to populate the Contact with the SIP equivalent of the tel URI of the calling party. > While I agree that the above sip uri format solves our > issue at hand, questions came to mind. For example, when calling > number IS present, do we use "tgrp" as part of tel-uri or do we use > sip uri similar to above? When the calling number is present, the Contact is populated with the SIP equivalent of the tel URI of the calling party. The username of anonymous MUST not be used in such cases. We will make this a normative behavior in the I-D. Questions? Comments? Thanks, - vijay _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Nov 29 17:06:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17728 for ; Mon, 29 Nov 2004 17:06:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtkd-00007P-VY for iptel-web-archive@ietf.org; Mon, 29 Nov 2004 17:12:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYsLY-00048P-Ks; Mon, 29 Nov 2004 15:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYs0Y-0008TP-R3 for iptel@megatron.ietf.org; Mon, 29 Nov 2004 15:20:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27499 for ; Mon, 29 Nov 2004 15:20:25 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYs5W-00028r-Ux for iptel@ietf.org; Mon, 29 Nov 2004 15:25:35 -0500 Received: from lion.cs.columbia.edu (IDENT:PhLVbS0QpHcOskTofbJdh5+6PRtKoeY+@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id iATKKNTO018581; Mon, 29 Nov 2004 15:20:23 -0500 (EST) Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id iATKKHTB024766 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 29 Nov 2004 15:20:17 -0500 Message-ID: <41AB847C.2060709@cs.columbia.edu> Date: Mon, 29 Nov 2004 15:20:12 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Iptel] Originating trunk group without calling number(Was[Re:Comments on Trunk Group ID]) References: <016501c4ce46$0172a660$eb00000a@SAJAK> <41AB6F99.1060005@lucent.com> In-Reply-To: <41AB6F99.1060005@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2004.11.29.19 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: IETF IPTEL WG , "'Takuya Sawada'" , Shan Lu X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > Continuing our leftover discussion on representing the > trunk group if the calling party was not present in an > incoming session setup request...a question for the IPTEL > co-chairs is embedded in the writeup below. > > With the subsequent confirmation from rfc2806bis author > regarding the inappropriateness of the following tel > URI (despite it being syntactically correct): Actually, this is no longer syntactically correct. The BNF has been fixed in 48h to agree with the intent. No other URI scheme allows empty URIs, as far as I know. > > tel:-;phone-context=example.com;tgrp=foo > > I would like to revisit my earlier suggestion to use > the following URI when the calling party is not known: > > sip:anonymous;phone-context=example.com;tgrp=foo@example.com > > If we go this route, Shan Lu raises good questions on the > choice of this URI. But I believe that these questions have > answers that fit within the current usage of SIP. Namely, _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 01:01:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26016 for ; Tue, 30 Nov 2004 01:01:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ19h-0002Fn-AY for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 01:06:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ13i-0008M5-3E; Tue, 30 Nov 2004 01:00:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ0xO-0006q5-Bx; Tue, 30 Nov 2004 00:53:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25625; Tue, 30 Nov 2004 00:53:43 -0500 (EST) Received: from mail4.telekom.de ([195.243.210.197]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ12O-00027G-CK; Tue, 30 Nov 2004 00:58:59 -0500 Received: from g8pbq.blf01.telekom.de by mail2.dmz.telekom.de with ESMTP; Tue, 30 Nov 2004 06:52:49 +0100 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Nov 2004 06:52:59 +0100 Message-Id: From: "Jesske, R" To: iptel@ietf.org, sip@ietf.org Date: Tue, 30 Nov 2004 06:52:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Iptel] Calling Party's Category X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Dear all, in the past there was a discussion regarding the specification of a Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What is the actual status of this activity. We are still interested in such kind of originating indication if the call/communication is coming from a normal SIP user or a SIP -Payphone or SIP-Hotelphone. Is there a interest from other parties in this issue? Best Regards Roland Deutsche Telekom AG T-Com Zentrale Roland Jesske, TE332-2 Section TE33; Signalling, Gateways and Switching Systems Am Kavalleriesand 3, 64295 Darmstadt, Germany Phone: +49 6151 83-5940 Fax: +49 6151 83-4577 email: r.jesske@t-com.net _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 10:18:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27087 for ; Tue, 30 Nov 2004 10:18:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9qk-00068z-Tt for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 10:23:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9e7-0007Tx-PB; Tue, 30 Nov 2004 10:10:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ9bh-0006B0-C5; Tue, 30 Nov 2004 10:07:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25721; Tue, 30 Nov 2004 10:07:55 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ9go-0005uZ-E2; Tue, 30 Nov 2004 10:13:15 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAUF7Ff16089; Tue, 30 Nov 2004 10:07:16 -0500 (EST) Received: from [47.130.24.149] (acart16j.ca.nortel.com [47.130.24.149]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14FSKSS; Tue, 30 Nov 2004 10:07:16 -0500 Message-ID: <41AC8CA2.8060509@nortelnetworks.com> Date: Tue, 30 Nov 2004 10:07:14 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jesske, R" Subject: Re: [Iptel] Calling Party's Category References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, sip@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit The question was what the requirement is for this sort of indication. How is it used? Jesske, R wrote: > Dear all, > in the past there was a discussion regarding the specification of a Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) > What is the actual status of this activity. > We are still interested in such kind of originating indication if the call/communication is coming from a normal SIP user or a SIP -Payphone or SIP-Hotelphone. > Is there a interest from other parties in this issue? > > Best Regards > > Roland > > Deutsche Telekom AG > T-Com Zentrale > Roland Jesske, TE332-2 > Section TE33; Signalling, Gateways and Switching Systems > Am Kavalleriesand 3, 64295 Darmstadt, Germany > Phone: +49 6151 83-5940 > Fax: +49 6151 83-4577 > email: r.jesske@t-com.net > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 11:01:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01223 for ; Tue, 30 Nov 2004 11:01:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAWx-0007Ap-08 for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 11:07:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZACH-0001DO-C0; Tue, 30 Nov 2004 10:45:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZA9R-0000Hx-Me; Tue, 30 Nov 2004 10:42:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29529; Tue, 30 Nov 2004 10:42:46 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAEZ-0006gv-96; Tue, 30 Nov 2004 10:48:07 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 16:42:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 16:42:07 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Iptel] Calling Party's Category Thread-Index: AcTW79aHtvI/2vXjS22xVk51c/AvHwAAyh6w From: "GARCIN Sebastien RD-CORE-ISS" To: "Tom Taylor" , "Jesske, R" X-OriginalArrivalTime: 30 Nov 2004 15:42:45.0328 (UTC) FILETIME=[3C7A9500:01C4D6F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: iptel@ietf.org, sip@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Hi, As an fixed line operator we also are interested in this feature and = would be happy that the IETF finally moves forward with this draft. This = type of parameter is widely signalled in ISDN/PSTN networks. In SIP (for = example) it is required in context of both: - pure SIP networks (e.g. in case of a SIP payphone), and - interworking with legacy networks=20 I think the uses case for this parameter will depend on the operator = service portfolio. For example, in France, the calling party's category = parameter is used for the Call Return service. Best regards, sebastien=20 -----Message d'origine----- De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part = de Tom Taylor Envoy=E9 : mardi 30 novembre 2004 16:07 =C0 : Jesske, R Cc : iptel@ietf.org; sip@ietf.org Objet : Re: [Iptel] Calling Party's Category The question was what the requirement is for this sort of indication. = How is it used? Jesske, R wrote: > Dear all, > in the past there was a discussion regarding the specification of a=20 > Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What = is the actual status of this activity. > We are still interested in such kind of originating indication if the = call/communication is coming from a normal SIP user or a SIP -Payphone = or SIP-Hotelphone.=20 > Is there a interest from other parties in this issue? >=20 > Best Regards >=20 > Roland >=20 > Deutsche Telekom AG > T-Com Zentrale > Roland Jesske, TE332-2 > Section TE33; Signalling, Gateways and Switching Systems Am=20 > Kavalleriesand 3, 64295 Darmstadt, Germany > Phone: +49 6151 83-5940=20 > Fax: +49 6151 83-4577=20 > email: r.jesske@t-com.net >=20 >=20 >=20 >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 >=20 -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 11:46:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05621 for ; Tue, 30 Nov 2004 11:46:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBE7-0008Qg-U8 for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 11:51:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZB0C-0006rt-SY; Tue, 30 Nov 2004 11:37:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZAnD-0003PX-3E; Tue, 30 Nov 2004 11:23:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03537; Tue, 30 Nov 2004 11:23:52 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAsK-0007oD-Uo; Tue, 30 Nov 2004 11:29:14 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Nov 2004 08:27:57 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAUGNKdG013497; Tue, 30 Nov 2004 08:23:21 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAUGMpvl001146; Tue, 30 Nov 2004 08:22:51 -0800 In-Reply-To: <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> References: <49E7012A614B024B80A7D175CB9A64ECB0491A@ftrdmel1.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <23EA088E-42EC-11D9-8CD3-000A95C73842@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 11:23:16 -0500 To: "GARCIN Sebastien RD-CORE-ISS" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101831772.374646"; x:"432200"; a:"rsa-sha1"; b:"nofws:3380"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"j29HsIm21RWrcGAEqmZ5oaMbr0XzETWpeBQnoA1nFs6igf7/UVxxIhRulvNVh" "jGKCaP84NHQaCN5uKkMyvC/tAM49JNU31aLMJ00+H+etfqPnqX7HGt3XpxqWR" "iX0NRh5/c8SlhS1FgZOhhc3zVrcMYXNdmGPJb2S4jz5rnEGQw="; c:"From: David R Oran "; c:"Subject: Re: [Sip] RE: [Iptel] Calling Party's Category"; c:"Date: Tue, 30 Nov 2004 11:23:16 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > Hi, > > As an fixed line operator we also are interested in this feature and=20= > would be happy that the IETF finally moves forward with this draft.=20 > This type of parameter is widely signalled in ISDN/PSTN networks. In=20= > SIP (for example) it is required in context of both: > > - pure SIP networks (e.g. in case of a SIP payphone), and > - interworking with legacy networks > > I think the uses case for this parameter will depend on the operator=20= > service portfolio. For example, in France, the calling party's=20 > category parameter is used for the Call Return service. > Could you explain a bit about how this is used? I, for one would find=20 it helpful and possibly a motivating use case. Also note that if this information is used for any security or=20 billing-sensitive operations, we have to deal with the issue of how to=20= secure it against spoofing (SIP UAs are generally not trusted). Would=20 you believe a call made by Robert Mitnick from a prison phone would=20 actually have a prison CPC in it's SIP headers :-) ? (Mitnick is a widely known phone freak and network hacker who served a=20= number of years in US prisons). > Best regards, > sebastien > > -----Message d'origine----- > De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part=20= > de Tom Taylor > Envoy=E9 : mardi 30 novembre 2004 16:07 > =C0 : Jesske, R > Cc : iptel@ietf.org; sip@ietf.org > Objet : Re: [Iptel] Calling Party's Category > > The question was what the requirement is for this sort of indication. =20= > How is it used? > > Jesske, R wrote: >> Dear all, >> in the past there was a discussion regarding the specification of a >> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What=20= >> is the actual status of this activity. >> We are still interested in such kind of originating indication if the=20= >> call/communication is coming from a normal SIP user or a SIP=20 >> -Payphone or SIP-Hotelphone. >> Is there a interest from other parties in this issue? >> >> Best Regards >> >> Roland >> >> Deutsche Telekom AG >> T-Com Zentrale >> Roland Jesske, TE332-2 >> Section TE33; Signalling, Gateways and Switching Systems Am >> Kavalleriesand 3, 64295 Darmstadt, Germany >> Phone: +49 6151 83-5940 >> Fax: +49 6151 83-4577 >> email: r.jesske@t-com.net >> >> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 12:09:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07897 for ; Tue, 30 Nov 2004 12:09:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBaQ-0000c6-Jl for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 12:14:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBHo-0003LJ-2I; Tue, 30 Nov 2004 11:55:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBEd-0002H2-ME; Tue, 30 Nov 2004 11:52:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06172; Tue, 30 Nov 2004 11:52:12 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBJm-00008K-Nd; Tue, 30 Nov 2004 11:57:35 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 17:52:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 17:51:33 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64ECB049CD@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Sip] RE: [Iptel] Calling Party's Category Thread-Index: AcTW+OnWQZTKFAeiT9uHpwiKSO9fTAAAt84w From: "GARCIN Sebastien RD-CORE-ISS" To: "David R Oran" X-OriginalArrivalTime: 30 Nov 2004 16:52:11.0734 (UTC) FILETIME=[EFD9AF60:01C4D6FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable In the Call Return service, a destination exchange memories an incoming = call which failed due to non-reply. If the call was orginated by a = payphone then the destination exchange does not memories the number = since it makes no sense in calling back a payphone.=20 BR, sebastien =20 -----Message d'origine----- De : David R Oran [mailto:oran@cisco.com]=20 Envoy=E9 : mardi 30 novembre 2004 17:23 =C0 : GARCIN Sebastien RD-CORE-ISS Cc : Jesske, R; Tom Taylor; iptel@ietf.org; sip@ietf.org Objet : Re: [Sip] RE: [Iptel] Calling Party's Category On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > Hi, > > As an fixed line operator we also are interested in this feature and=20 > would be happy that the IETF finally moves forward with this draft. > This type of parameter is widely signalled in ISDN/PSTN networks. In=20 > SIP (for example) it is required in context of both: > > - pure SIP networks (e.g. in case of a SIP payphone), and > - interworking with legacy networks > > I think the uses case for this parameter will depend on the operator=20 > service portfolio. For example, in France, the calling party's=20 > category parameter is used for the Call Return service. > Could you explain a bit about how this is used? I, for one would find it = helpful and possibly a motivating use case. Also note that if this information is used for any security or = billing-sensitive operations, we have to deal with the issue of how to = secure it against spoofing (SIP UAs are generally not trusted). Would = you believe a call made by Robert Mitnick from a prison phone would = actually have a prison CPC in it's SIP headers :-) ? (Mitnick is a widely known phone freak and network hacker who served a = number of years in US prisons). > Best regards, > sebastien > > -----Message d'origine----- > De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la part = > de Tom Taylor Envoy=E9 : mardi 30 novembre 2004 16:07 =C0 : Jesske, R = Cc :=20 > iptel@ietf.org; sip@ietf.org Objet : Re: [Iptel] Calling Party's=20 > Category > > The question was what the requirement is for this sort of indication. = > How is it used? > > Jesske, R wrote: >> Dear all, >> in the past there was a discussion regarding the specification of a=20 >> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What=20 >> is the actual status of this activity. >> We are still interested in such kind of originating indication if the = >> call/communication is coming from a normal SIP user or a SIP=20 >> -Payphone or SIP-Hotelphone. >> Is there a interest from other parties in this issue? >> >> Best Regards >> >> Roland >> >> Deutsche Telekom AG >> T-Com Zentrale >> Roland Jesske, TE332-2 >> Section TE33; Signalling, Gateways and Switching Systems Am=20 >> Kavalleriesand 3, 64295 Darmstadt, Germany >> Phone: +49 6151 83-5940 >> Fax: +49 6151 83-4577 >> email: r.jesske@t-com.net >> >> >> >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> > > -- > Tom Taylor > Carrier VoIP Standards Development > Nortel Networks > Phone +1 613 763 1496 (ESN 393-1496) > E-mail: taylor@nortelnetworks.com > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 12:29:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09752 for ; Tue, 30 Nov 2004 12:29:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBu4-0001BI-VA for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 12:35:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBWu-0008IB-Qm; Tue, 30 Nov 2004 12:11:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBKE-0004Fp-8z for iptel@megatron.ietf.org; Tue, 30 Nov 2004 11:58:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06990 for ; Tue, 30 Nov 2004 11:57:59 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBPN-0000Jb-Ao for iptel@ietf.org; Tue, 30 Nov 2004 12:03:21 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 30 Nov 2004 09:03:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAUGvN9N013153; Tue, 30 Nov 2004 08:57:23 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAUGv0Kr001415; Tue, 30 Nov 2004 08:57:00 -0800 In-Reply-To: <49E7012A614B024B80A7D175CB9A64ECB049CD@ftrdmel1.rd.francetelecom.fr> References: <49E7012A614B024B80A7D175CB9A64ECB049CD@ftrdmel1.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 11:57:25 -0500 To: "GARCIN Sebastien RD-CORE-ISS" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101833821.130643"; x:"432200"; a:"rsa-sha1"; b:"nofws:4322"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"WidYgX6iZIXsJ6I+XDaQOyeHRxzL4Zlhyqd7+IYkNNux44s+7vH2fuxJNntzs" "dan02848TRmCJY5fqR/8yTBgzqm4pMeVMtDIojKys6Maff2cAryF0eThJl9kj" "Njvlb4e5j3d/8z75ORg0Cu+UML65gV/kwgJ7p832MiUu04HIE="; c:"From: David R Oran "; c:"Subject: Re: [Sip] RE: [Iptel] Calling Party's Category"; c:"Date: Tue, 30 Nov 2004 11:57:25 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: "'list iptel'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable On Nov 30, 2004, at 11:51 AM, GARCIN Sebastien RD-CORE-ISS wrote: > In the Call Return service, a destination exchange memories an=20 > incoming call which failed due to non-reply. If the call was orginated=20= > by a payphone then the destination exchange does not memories the=20 > number since it makes no sense in calling back a payphone. > In the US it does. Do payphones in France not accept incoming calls? > BR, > sebastien > > > -----Message d'origine----- > De : David R Oran [mailto:oran@cisco.com] > Envoy=E9 : mardi 30 novembre 2004 17:23 > =C0 : GARCIN Sebastien RD-CORE-ISS > Cc : Jesske, R; Tom Taylor; iptel@ietf.org; sip@ietf.org > Objet : Re: [Sip] RE: [Iptel] Calling Party's Category > > > On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > >> Hi, >> >> As an fixed line operator we also are interested in this feature and >> would be happy that the IETF finally moves forward with this draft. >> This type of parameter is widely signalled in ISDN/PSTN networks. In >> SIP (for example) it is required in context of both: >> >> - pure SIP networks (e.g. in case of a SIP payphone), and >> - interworking with legacy networks >> >> I think the uses case for this parameter will depend on the operator >> service portfolio. For example, in France, the calling party's >> category parameter is used for the Call Return service. >> > Could you explain a bit about how this is used? I, for one would find=20= > it helpful and possibly a motivating use case. > > Also note that if this information is used for any security or=20 > billing-sensitive operations, we have to deal with the issue of how to=20= > secure it against spoofing (SIP UAs are generally not trusted). Would=20= > you believe a call made by Robert Mitnick from a prison phone would=20 > actually have a prison CPC in it's SIP headers :-) ? > > (Mitnick is a widely known phone freak and network hacker who served a=20= > number of years in US prisons). > >> Best regards, >> sebastien >> >> -----Message d'origine----- >> De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la = part >> de Tom Taylor Envoy=E9 : mardi 30 novembre 2004 16:07 =C0 : Jesske, R = Cc : >> iptel@ietf.org; sip@ietf.org Objet : Re: [Iptel] Calling Party's >> Category >> >> The question was what the requirement is for this sort of indication. >> How is it used? >> >> Jesske, R wrote: >>> Dear all, >>> in the past there was a discussion regarding the specification of a >>> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What >>> is the actual status of this activity. >>> We are still interested in such kind of originating indication if = the >>> call/communication is coming from a normal SIP user or a SIP >>> -Payphone or SIP-Hotelphone. >>> Is there a interest from other parties in this issue? >>> >>> Best Regards >>> >>> Roland >>> >>> Deutsche Telekom AG >>> T-Com Zentrale >>> Roland Jesske, TE332-2 >>> Section TE33; Signalling, Gateways and Switching Systems Am >>> Kavalleriesand 3, 64295 Darmstadt, Germany >>> Phone: +49 6151 83-5940 >>> Fax: +49 6151 83-4577 >>> email: r.jesske@t-com.net >>> >>> >>> >>> >>> _______________________________________________ >>> Iptel mailing list >>> Iptel@ietf.org >>> https://www1.ietf.org/mailman/listinfo/iptel >>> >>> >> >> -- >> Tom Taylor >> Carrier VoIP Standards Development >> Nortel Networks >> Phone +1 613 763 1496 (ESN 393-1496) >> E-mail: taylor@nortelnetworks.com >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use >> sip-implementors@cs.columbia.edu for questions on current sip Use >> sipping@ietf.org for new developments on the application of sip >> > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 12:34:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10429 for ; Tue, 30 Nov 2004 12:34:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZByY-0001OC-Oj for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 12:39:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBp6-0006vx-Qy; Tue, 30 Nov 2004 12:29:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBXF-0008NY-QZ for iptel@megatron.ietf.org; Tue, 30 Nov 2004 12:11:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08015 for ; Tue, 30 Nov 2004 12:11:27 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CZBcE-0000e1-00 for iptel@ietf.org; Tue, 30 Nov 2004 12:16:49 -0500 Received: (qmail 51162 invoked by uid 1014); 30 Nov 2004 17:10:40 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.80. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.033662 secs); 30 Nov 2004 17:10:40 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 30 Nov 2004 17:10:40 -0000 From: "Shan Lu" To: "'Henning Schulzrinne'" , "'Vijay K. Gurbani'" Subject: RE: [Iptel] Originating trunk group without calling number(Was[Re:Comments on Trunk Group ID]) Date: Tue, 30 Nov 2004 12:12:00 -0500 Message-ID: <015901c4d6ff$b4384e50$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <41AB847C.2060709@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "'IETF IPTEL WG'" , "'Takuya Sawada'" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit >-----Original Message----- >From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >Sent: Monday, November 29, 2004 3:20 PM >To: Vijay K. Gurbani >Cc: Shan Lu; 'Takuya Sawada'; IETF IPTEL WG >Subject: Re: [Iptel] Originating trunk group without calling >number(Was[Re:Comments on Trunk Group ID]) > >Vijay K. Gurbani wrote: >> Continuing our leftover discussion on representing the >> trunk group if the calling party was not present in an >> incoming session setup request...a question for the IPTEL >> co-chairs is embedded in the writeup below. >> >> With the subsequent confirmation from rfc2806bis author >> regarding the inappropriateness of the following tel >> URI (despite it being syntactically correct): > >Actually, this is no longer syntactically correct. The BNF has been >fixed in 48h to agree with the intent. No other URI scheme >allows empty >URIs, as far as I know. > >> tel:-;phone-context=example.com;tgrp=foo >> Fixing the BNF does not make the issue disappear. The issue is, tel uri, as currently defined, does not allow expression of unavailable phone digits. For example, "tel:xxx;phone-context=internal" can mean something even when "xxx" isn't there. Think of a calling number that is "internal" but has requested privacy. I am not for or against any particular way to indicate empty phone number (which may or may not lead to empty uri). But I think -A- way will be desirable. Regards, Shan Lu _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 12:40:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12208 for ; Tue, 30 Nov 2004 12:40:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZC4a-0001dY-Ff for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 12:45:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBpT-00077w-4V; Tue, 30 Nov 2004 12:30:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZBeX-0002op-6Y for iptel@megatron.ietf.org; Tue, 30 Nov 2004 12:19:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08711 for ; Tue, 30 Nov 2004 12:18:58 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBjW-0000sz-I9 for iptel@ietf.org; Tue, 30 Nov 2004 12:24:21 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Nov 2004 18:18:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 18:18:09 +0100 Message-ID: <49E7012A614B024B80A7D175CB9A64ECB04A03@ftrdmel1.rd.francetelecom.fr> Thread-Topic: [Sip] RE: [Iptel] Calling Party's Category Thread-Index: AcTW/a3LC+z6Z0GQSiCaZTd8uFUnWgAAahyw From: "GARCIN Sebastien RD-CORE-ISS" To: "David R Oran" X-OriginalArrivalTime: 30 Nov 2004 17:18:47.0198 (UTC) FILETIME=[A6D22BE0:01C4D700] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: list iptel X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable ????=20 In the example, the payphone is the calling party.=20 1 - a payphone establishes a call,=20 2 - upon receipt of the incoming call request the destination exchange = alerts the called party 3 - the called party does not reply=20 Given that the calling party is a payphone (and not an ordinary = subscriber), the destination exchange does not memorise the number which = it normally does for if the calling party is an ordinary subscriber. =20 -----Message d'origine----- De : David R Oran [mailto:oran@cisco.com]=20 Envoy=E9 : mardi 30 novembre 2004 17:57 =C0 : GARCIN Sebastien RD-CORE-ISS Cc : 'list iptel' Objet : Re: [Sip] RE: [Iptel] Calling Party's Category On Nov 30, 2004, at 11:51 AM, GARCIN Sebastien RD-CORE-ISS wrote: > In the Call Return service, a destination exchange memories an=20 > incoming call which failed due to non-reply. If the call was orginated = > by a payphone then the destination exchange does not memories the=20 > number since it makes no sense in calling back a payphone. > In the US it does. Do payphones in France not accept incoming calls? > BR, > sebastien > > > -----Message d'origine----- > De : David R Oran [mailto:oran@cisco.com] Envoy=E9 : mardi 30 novembre = > 2004 17:23 =C0 : GARCIN Sebastien RD-CORE-ISS Cc : Jesske, R; Tom=20 > Taylor; iptel@ietf.org; sip@ietf.org Objet : Re: [Sip] RE: [Iptel]=20 > Calling Party's Category > > > On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > >> Hi, >> >> As an fixed line operator we also are interested in this feature and=20 >> would be happy that the IETF finally moves forward with this draft. >> This type of parameter is widely signalled in ISDN/PSTN networks. In=20 >> SIP (for example) it is required in context of both: >> >> - pure SIP networks (e.g. in case of a SIP payphone), and >> - interworking with legacy networks >> >> I think the uses case for this parameter will depend on the operator=20 >> service portfolio. For example, in France, the calling party's=20 >> category parameter is used for the Call Return service. >> > Could you explain a bit about how this is used? I, for one would find=20 > it helpful and possibly a motivating use case. > > Also note that if this information is used for any security or=20 > billing-sensitive operations, we have to deal with the issue of how to = > secure it against spoofing (SIP UAs are generally not trusted). Would=20 > you believe a call made by Robert Mitnick from a prison phone would=20 > actually have a prison CPC in it's SIP headers :-) ? > > (Mitnick is a widely known phone freak and network hacker who served a = > number of years in US prisons). > >> Best regards, >> sebastien >> >> -----Message d'origine----- >> De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la=20 >> part de Tom Taylor Envoy=E9 : mardi 30 novembre 2004 16:07 =C0 : = Jesske, R Cc : >> iptel@ietf.org; sip@ietf.org Objet : Re: [Iptel] Calling Party's=20 >> Category >> >> The question was what the requirement is for this sort of indication. >> How is it used? >> >> Jesske, R wrote: >>> Dear all, >>> in the past there was a discussion regarding the specification of a=20 >>> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) What = >>> is the actual status of this activity. >>> We are still interested in such kind of originating indication if=20 >>> the call/communication is coming from a normal SIP user or a SIP=20 >>> -Payphone or SIP-Hotelphone. >>> Is there a interest from other parties in this issue? >>> >>> Best Regards >>> >>> Roland >>> >>> Deutsche Telekom AG >>> T-Com Zentrale >>> Roland Jesske, TE332-2 >>> Section TE33; Signalling, Gateways and Switching Systems Am=20 >>> Kavalleriesand 3, 64295 Darmstadt, Germany >>> Phone: +49 6151 83-5940 >>> Fax: +49 6151 83-4577 >>> email: r.jesske@t-com.net >>> >>> >>> >>> >>> _______________________________________________ >>> Iptel mailing list >>> Iptel@ietf.org >>> https://www1.ietf.org/mailman/listinfo/iptel >>> >>> >> >> -- >> Tom Taylor >> Carrier VoIP Standards Development >> Nortel Networks >> Phone +1 613 763 1496 (ESN 393-1496) >> E-mail: taylor@nortelnetworks.com >> >> _______________________________________________ >> Iptel mailing list >> Iptel@ietf.org >> https://www1.ietf.org/mailman/listinfo/iptel >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip >> > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 12:59:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14325 for ; Tue, 30 Nov 2004 12:59:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZCMU-0002Bp-3y for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 13:04:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZCAk-0004Ri-2l; Tue, 30 Nov 2004 12:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZC1b-0002Cz-JY for iptel@megatron.ietf.org; Tue, 30 Nov 2004 12:42:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12484 for ; Tue, 30 Nov 2004 12:42:48 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZC6l-0001hk-5L for iptel@ietf.org; Tue, 30 Nov 2004 12:48:11 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 30 Nov 2004 09:47:00 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAUHg7AC017477; Tue, 30 Nov 2004 09:42:07 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iAUHfrQd001910; Tue, 30 Nov 2004 09:41:53 -0800 In-Reply-To: <49E7012A614B024B80A7D175CB9A64ECB04A03@ftrdmel1.rd.francetelecom.fr> References: <49E7012A614B024B80A7D175CB9A64ECB04A03@ftrdmel1.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2E75CBD8-42F7-11D9-8CD3-000A95C73842@cisco.com> Content-Transfer-Encoding: quoted-printable From: David R Oran Subject: Re: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 12:42:18 -0500 To: "GARCIN Sebastien RD-CORE-ISS" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101836514.181713"; x:"432200"; a:"rsa-sha1"; b:"nofws:5707"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ILN7QiWsBj4XxTz7VxGEhdyDiJkN5tIuz4yPnks+BAEHlLHrYhpXccAQAp+W7" "y8gyJZINpahv1JsmgCkWJI7aBdQpi79ttGHGnfWyypOUBxItglnAJ0a7iBYrL" "JF4b7EXGg7lF/yXPvhcZguAL8GnEBT9tTYIB5V6WQlIhhZiVI="; c:"From: David R Oran "; c:"Subject: Re: [Sip] RE: [Iptel] Calling Party's Category"; c:"Date: Tue, 30 Nov 2004 12:42:18 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: quoted-printable Cc: list iptel X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: quoted-printable On Nov 30, 2004, at 12:18 PM, GARCIN Sebastien RD-CORE-ISS wrote: > ???? > > In the example, the payphone is the calling party. > > 1 - a payphone establishes a call, > 2 - upon receipt of the incoming call request the destination exchange=20= > alerts the called party > 3 - the called party does not reply > > Given that the calling party is a payphone (and not an ordinary=20 > subscriber), the destination exchange does not memorise the number=20 > which it normally does for if the calling party is an ordinary=20 > subscriber. > Sorry if I was too terse. Take your scenario where the callee doesn't=20 answer. The caller at the payphone is standing around waiting. The=20 callee comes out of the bathroom, sees he has a missed call, and hits=20 call return. Payphone rings. Waiting person picks up. You see this sort of thing in the movies all the time :-) > > -----Message d'origine----- > De : David R Oran [mailto:oran@cisco.com] > Envoy=E9 : mardi 30 novembre 2004 17:57 > =C0 : GARCIN Sebastien RD-CORE-ISS > Cc : 'list iptel' > Objet : Re: [Sip] RE: [Iptel] Calling Party's Category > > > On Nov 30, 2004, at 11:51 AM, GARCIN Sebastien RD-CORE-ISS wrote: > >> In the Call Return service, a destination exchange memories an >> incoming call which failed due to non-reply. If the call was = orginated >> by a payphone then the destination exchange does not memories the >> number since it makes no sense in calling back a payphone. >> > In the US it does. Do payphones in France not accept incoming calls? > >> BR, >> sebastien >> >> >> -----Message d'origine----- >> De : David R Oran [mailto:oran@cisco.com] Envoy=E9 : mardi 30 = novembre >> 2004 17:23 =C0 : GARCIN Sebastien RD-CORE-ISS Cc : Jesske, R; Tom >> Taylor; iptel@ietf.org; sip@ietf.org Objet : Re: [Sip] RE: [Iptel] >> Calling Party's Category >> >> >> On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: >> >>> Hi, >>> >>> As an fixed line operator we also are interested in this feature and >>> would be happy that the IETF finally moves forward with this draft. >>> This type of parameter is widely signalled in ISDN/PSTN networks. In >>> SIP (for example) it is required in context of both: >>> >>> - pure SIP networks (e.g. in case of a SIP payphone), and >>> - interworking with legacy networks >>> >>> I think the uses case for this parameter will depend on the operator >>> service portfolio. For example, in France, the calling party's >>> category parameter is used for the Call Return service. >>> >> Could you explain a bit about how this is used? I, for one would find >> it helpful and possibly a motivating use case. >> >> Also note that if this information is used for any security or >> billing-sensitive operations, we have to deal with the issue of how = to >> secure it against spoofing (SIP UAs are generally not trusted). Would >> you believe a call made by Robert Mitnick from a prison phone would >> actually have a prison CPC in it's SIP headers :-) ? >> >> (Mitnick is a widely known phone freak and network hacker who served = a >> number of years in US prisons). >> >>> Best regards, >>> sebastien >>> >>> -----Message d'origine----- >>> De : iptel-bounces@ietf.org [mailto:iptel-bounces@ietf.org] De la >>> part de Tom Taylor Envoy=E9 : mardi 30 novembre 2004 16:07 =C0 : = Jesske,=20 >>> R Cc : >>> iptel@ietf.org; sip@ietf.org Objet : Re: [Iptel] Calling Party's >>> Category >>> >>> The question was what the requirement is for this sort of = indication. >>> How is it used? >>> >>> Jesske, R wrote: >>>> Dear all, >>>> in the past there was a discussion regarding the specification of a >>>> Calling Party's Category for SIP. (draft-mahy-iptel-cpc-00.txt) = What >>>> is the actual status of this activity. >>>> We are still interested in such kind of originating indication if >>>> the call/communication is coming from a normal SIP user or a SIP >>>> -Payphone or SIP-Hotelphone. >>>> Is there a interest from other parties in this issue? >>>> >>>> Best Regards >>>> >>>> Roland >>>> >>>> Deutsche Telekom AG >>>> T-Com Zentrale >>>> Roland Jesske, TE332-2 >>>> Section TE33; Signalling, Gateways and Switching Systems Am >>>> Kavalleriesand 3, 64295 Darmstadt, Germany >>>> Phone: +49 6151 83-5940 >>>> Fax: +49 6151 83-4577 >>>> email: r.jesske@t-com.net >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Iptel mailing list >>>> Iptel@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/iptel >>>> >>>> >>> >>> -- >>> Tom Taylor >>> Carrier VoIP Standards Development >>> Nortel Networks >>> Phone +1 613 763 1496 (ESN 393-1496) >>> E-mail: taylor@nortelnetworks.com >>> >>> _______________________________________________ >>> Iptel mailing list >>> Iptel@ietf.org >>> https://www1.ietf.org/mailman/listinfo/iptel >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> David R. Oran >> Cisco Fellow >> Cisco Systems >> 7 Ladyslipper Lane >> Acton, MA 01720 USA >> Tel: +1 978 264 2048 >> Email: oran@cisco.com >> >> > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 14:08:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21311 for ; Tue, 30 Nov 2004 14:08:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDRp-0004CZ-Ui for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 14:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDG9-0002D9-O8; Tue, 30 Nov 2004 14:01:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZD65-0007Vp-3N; Tue, 30 Nov 2004 13:51:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19482; Tue, 30 Nov 2004 13:51:31 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDBF-0003g6-BT; Tue, 30 Nov 2004 13:56:53 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iAUIorS20101; Tue, 30 Nov 2004 13:50:53 -0500 (EST) Received: from [47.130.24.149] (acart16j.ca.nortel.com [47.130.24.149]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W14FSMZH; Tue, 30 Nov 2004 13:50:53 -0500 Message-ID: <41ACC10C.2090206@nortelnetworks.com> Date: Tue, 30 Nov 2004 13:50:52 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nguyen, An" Subject: Re: [Iptel] Calling Party's Category References: <7F18415E4D63CB45BB9B3A591F68D12D0765166C@emshqs1.ncr.disa.mil> In-Reply-To: <7F18415E4D63CB45BB9B3A591F68D12D0765166C@emshqs1.ncr.disa.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: iptel@ietf.org, "Jesske, R" , sipping@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Jonathan, I hope I am stating this correctly. The Chair's proposal at the meeting was that this draft be dropped, because with SIP-T defined, there is no need to define other means in SIP to carry signalling destined specifically to the PSTN. However, if use cases can be provided which demonstrate a requirement to be met in the pure SIP environment, work can be done (probably in SIPPING) to meet those requirements. Nguyen, An wrote: > Mr. Taylor; > > I am just curious ... What is the status of the Internet Draft? > > An > > [snip] -- Tom Taylor Carrier VoIP Standards Development Nortel Networks Phone +1 613 763 1496 (ESN 393-1496) E-mail: taylor@nortelnetworks.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 17:33:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23730 for ; Tue, 30 Nov 2004 17:33:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZGe1-0005Lg-DO for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 17:38:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGDU-000720-N2; Tue, 30 Nov 2004 17:11:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFE5-0006tR-3R; Tue, 30 Nov 2004 16:07:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06904; Tue, 30 Nov 2004 16:07:54 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m15.mx.aol.com ([64.12.138.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFJF-0008Lj-8U; Tue, 30 Nov 2004 16:13:18 -0500 Received: from Mpierce1@aol.com by imo-m15.mx.aol.com (mail_out_v37_r3.8.) id c.74.47df70e2 (3980); Tue, 30 Nov 2004 16:06:13 -0500 (EST) Message-ID: <74.47df70e2.2ede3ac5@aol.com> Date: Tue, 30 Nov 2004 16:06:13 EST Subject: Re: [Sip] RE: [Iptel] Calling Party's Category To: oran@cisco.com, sebastien.garcin@francetelecom.com MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: R.Jesske@t-com.net, iptel@ietf.org, taylor@nortelnetworks.com, sip@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380703669==" Sender: iptel-bounces@ietf.org Errors-To: iptel-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --===============1380703669== Content-Type: multipart/alternative; boundary="part1_74.47df70e2.2ede3ac5_boundary" --part1_74.47df70e2.2ede3ac5_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/30/2004 11:49:18 AM Eastern Standard Time, oran@cisco.com writes: > Also note that if this information is used for any security or > billing-sensitive operations, we have to deal with the issue of how to > secure it against spoofing (SIP UAs are generally not trusted). Would > you believe a call made by Robert Mitnick from a prison phone would > actually have a prison CPC in it's SIP headers :-) ? > Of course, this shows a basic difference in the way this capability is handled in SIP vs today's telephone network. It's an important thing to deal with, since many of these things are mandated by law. For example, I believe the requirement to identify calls from a prison as such is mandated. In today's network, in order to provide assurance that the call is properly marked, not just for CPC but calling party ID as well, the phone in the prison is rnot esponsible for the marking. The switch outside the prison marks any call that comes over that pair of wires. Robert Mitnick had no opportunity to change that marking. The issue for SIP is to provide the same level of assurance for such functions. I'm sure anxious to hear a resolution to this problem, since it keeps coming back. CPC is not unique in this regard, so a general solution is needed. Mike Pierce Artel --part1_74.47df70e2.2ede3ac5_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/30/2004 11:49:18 AM Eastern Standard Time, oran@cisco.com writes:


Also note that if this info= rmation is used for any security or=20
billing-sensitive operations, we have to deal with the issue of how to=20
secure it against spoofing (SIP UAs are generally not trusted). Would=20
you believe a call made by Robert Mitnick from a prison phone would=20
actually have a prison CPC in it's SIP headers :-) ?


Of course, this shows a basic difference in the way this capability is h= andled in SIP vs today's telephone network. It's an important thing to deal=20= with, since many of these things are mandated by law. For example, I believe= the requirement to identify calls from a prison as such is mandated.

In today's network, in order to provide assurance that the call is prope= rly marked, not just for CPC but calling party ID as well, the phone in the=20= prison is rnot esponsible for the marking. The switch outside the prison mar= ks any call that comes over that pair of wires. Robert Mitnick had no opport= unity to change that marking.

The issue for SIP is to provide the same level of assurance for such fun= ctions. I'm sure anxious to hear a resolution to this problem, since it keep= s coming back. CPC is not unique in this regard, so a general solution is ne= eded.

Mike Pierce
Artel
--part1_74.47df70e2.2ede3ac5_boundary-- --===============1380703669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1380703669==-- From iptel-bounces@ietf.org Tue Nov 30 19:56:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07221 for ; Tue, 30 Nov 2004 19:56:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIsh-0000Rm-TY for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 20:02:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIaz-0000fB-FS; Tue, 30 Nov 2004 19:43:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIXl-0007a4-2j; Tue, 30 Nov 2004 19:40:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05339; Tue, 30 Nov 2004 19:40:25 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIcy-0008Q8-S2; Tue, 30 Nov 2004 19:45:53 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iB10dtxg003341; Wed, 1 Dec 2004 00:39:55 GMT Received: by stntimc1.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 30 Nov 2004 19:39:55 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089985@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'Adam Roach'" , David R Oran Subject: RE: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 19:39:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 I view these sorts of security attributes as elements of trait-based authorization. The calling party's category requires the sort of pre-arrangement and federation to which something like SAML naturally lends itself. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, November 30, 2004 9:27 PM > To: David R Oran > Cc: Jesske, R; iptel@ietf.org; Tom Taylor; sip@ietf.org > Subject: Re: [Sip] RE: [Iptel] Calling Party's Category > > > David R Oran wrote: > > > > > On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > > > >> As an fixed line operator we also are interested in this > feature and > >> would be happy that the IETF finally moves forward with > this draft. > >> This type of parameter is widely signalled in ISDN/PSTN > networks. In > >> SIP (for example) it is required in context of both: > >> > >> - pure SIP networks (e.g. in case of a SIP payphone), and > >> - interworking with legacy networks > >> > >> I think the uses case for this parameter will depend on > the operator > >> service portfolio. For example, in France, the calling party's > >> category parameter is used for the Call Return service. > >> > > Could you explain a bit about how this is used? I, for one > would find > > it helpful and possibly a motivating use case. > > > I'm equally confused. I'm familiar with the calling party category in > ISUP, which works only because of the walled-garden nature of the SS7 > network. Without that, there are really two major factors around this > which need to be characterized: > > 1. Who is authorized to assert a particular calling party category? > This is much trickier than the identity problem; with > identity, we > can trust that a domain is the authority for the use of > user names > in that domain. For calling party category, there is no such > relationship. For example, it would probably not be valid for a > domain of "adamroach.com" to assert a calling party category of > "priority," "operator," or "police." > 2. Under which circumstances is the calling party category required > to be present? Is there some architectural mechanism that can be > used to enforce this? (We don't need to define it, but there > should at least be some idea about whether it's > possible). If not, > then there is no purpose in coming up with a protocol mechanism > for conveying such information. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 21:55:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16907 for ; Tue, 30 Nov 2004 21:55:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZKjG-00039D-R9 for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 22:00:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKZH-00070s-R0; Tue, 30 Nov 2004 21:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKYd-0006i0-PZ; Tue, 30 Nov 2004 21:49:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16034; Tue, 30 Nov 2004 21:49:29 -0500 (EST) Received: from [211.239.157.46] (helo=nt37.direct.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZKdr-0002yc-Nq; Tue, 30 Nov 2004 21:54:56 -0500 Received: from mail pickup service by nt37.direct.co.kr with Microsoft SMTPSVC; Wed, 1 Dec 2004 11:49:18 +0900 Received: from megatron.ietf.org [132.151.6.71] by mail4.direct.co.kr with ESMTP (SMTPD32-7.15) id A6CB5C80070; Wed, 01 Dec 2004 09:56:43 +0900 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIax-0000em-SG; Tue, 30 Nov 2004 19:43:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZIXl-0007a4-2j; Tue, 30 Nov 2004 19:40:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05339; Tue, 30 Nov 2004 19:40:25 -0500 (EST) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZIcy-0008Q8-S2; Tue, 30 Nov 2004 19:45:53 -0500 Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iB10dtxg003341; Wed, 1 Dec 2004 00:39:55 GMT Received: by stntimc1.neustar.com with Internet Mail Service (5.5.2657.72) id ; Tue, 30 Nov 2004 19:39:55 -0500 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089985@stntexch03.cis.neustar.com> From: "Peterson, Jon" To: "'Adam Roach'" , David R Oran Subject: RE: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 19:39:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 01 Dec 2004 02:49:18.0110 (UTC) FILETIME=[5A08D3E0:01C4D750] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "Jesske, R" , iptel@ietf.org, Tom Taylor , sip@ietf.org X-BeenThere: iptel@ietf.org 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 I view these sorts of security attributes as elements of trait-based authorization. The calling party's category requires the sort of pre-arrangement and federation to which something like SAML naturally lends itself. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, November 30, 2004 9:27 PM > To: David R Oran > Cc: Jesske, R; iptel@ietf.org; Tom Taylor; sip@ietf.org > Subject: Re: [Sip] RE: [Iptel] Calling Party's Category > > > David R Oran wrote: > > > > > On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: > > > >> As an fixed line operator we also are interested in this > feature and > >> would be happy that the IETF finally moves forward with > this draft. > >> This type of parameter is widely signalled in ISDN/PSTN > networks. In > >> SIP (for example) it is required in context of both: > >> > >> - pure SIP networks (e.g. in case of a SIP payphone), and > >> - interworking with legacy networks > >> > >> I think the uses case for this parameter will depend on > the operator > >> service portfolio. For example, in France, the calling party's > >> category parameter is used for the Call Return service. > >> > > Could you explain a bit about how this is used? I, for one > would find > > it helpful and possibly a motivating use case. > > > I'm equally confused. I'm familiar with the calling party category in > ISUP, which works only because of the walled-garden nature of the SS7 > network. Without that, there are really two major factors around this > which need to be characterized: > > 1. Who is authorized to assert a particular calling party category? > This is much trickier than the identity problem; with > identity, we > can trust that a domain is the authority for the use of > user names > in that domain. For calling party category, there is no such > relationship. For example, it would probably not be valid for a > domain of "adamroach.com" to assert a calling party category of > "priority," "operator," or "police." > 2. Under which circumstances is the calling party category required > to be present? Is there some architectural mechanism that can be > used to enforce this? (We don't need to define it, but there > should at least be some idea about whether it's > possible). If not, > then there is no purpose in coming up with a protocol mechanism > for conveying such information. > > /a > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 22:07:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18231 for ; Tue, 30 Nov 2004 22:07:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZKvO-0003RG-Kz for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 22:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKow-0003K8-K1; Tue, 30 Nov 2004 22:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKka-0001sF-7Q for iptel@megatron.ietf.org; Tue, 30 Nov 2004 22:01:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17589 for ; Tue, 30 Nov 2004 22:01:49 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZKpn-0003JK-Kd for iptel@ietf.org; Tue, 30 Nov 2004 22:07:17 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2004 19:01:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iB131HYr005941; Tue, 30 Nov 2004 19:01:17 -0800 (PST) Received: from [10.32.245.156] (stealth-10-32-245-156.cisco.com [10.32.245.156]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id iB130lGR006458; Tue, 30 Nov 2004 19:00:47 -0800 In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD597089985@stntexch03.cis.neustar.com> References: <24EAE5D4448B9D4592C6D234CBEBD597089985@stntexch03.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4314C7D1-4345-11D9-8CD3-000A95C73842@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] RE: [Iptel] Calling Party's Category Date: Tue, 30 Nov 2004 22:01:14 -0500 To: "Peterson, Jon" X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101870048.289774"; x:"432200"; a:"rsa-sha1"; b:"nofws:3652"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"caNxJqLjPj/8dVfypzeFt7g5UZ6eWD7Eh/zivWVOzQJcAkHP+JIiJdT/7kNwY" "TlDj/vknSAxA4sc7cKiLEZoBzEBoU2H6e4K+0zGN+onNI/xsptWMPZpyawEf/" "5WXSybSJkt8f3ifTyNp2hDBchfvGKtIWWjVYZtHGKnr73xcvs="; c:"From: David R Oran "; c:"Subject: Re: [Sip] RE: [Iptel] Calling Party's Category"; c:"Date: Tue, 30 Nov 2004 22:01:14 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: list iptel X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit On Nov 30, 2004, at 7:39 PM, Peterson, Jon wrote: > > I view these sorts of security attributes as elements of trait-based > authorization. The calling party's category requires the sort of > pre-arrangement and federation to which something like SAML naturally > lends > itself. > Yes. I agree this is the right approach to any characteristic of an endpoint/subscriber that has to be securely asserted, and particularly, which should not be easily repudiatable. Dave. > Jon Peterson > NeuStar, Inc. > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Tuesday, November 30, 2004 9:27 PM >> To: David R Oran >> Cc: Jesske, R; iptel@ietf.org; Tom Taylor; sip@ietf.org >> Subject: Re: [Sip] RE: [Iptel] Calling Party's Category >> >> >> David R Oran wrote: >> >>> >>> On Nov 30, 2004, at 10:42 AM, GARCIN Sebastien RD-CORE-ISS wrote: >>> >>>> As an fixed line operator we also are interested in this >> feature and >>>> would be happy that the IETF finally moves forward with >> this draft. >>>> This type of parameter is widely signalled in ISDN/PSTN >> networks. In >>>> SIP (for example) it is required in context of both: >>>> >>>> - pure SIP networks (e.g. in case of a SIP payphone), and >>>> - interworking with legacy networks >>>> >>>> I think the uses case for this parameter will depend on >> the operator >>>> service portfolio. For example, in France, the calling party's >>>> category parameter is used for the Call Return service. >>>> >>> Could you explain a bit about how this is used? I, for one >> would find >>> it helpful and possibly a motivating use case. >> >> >> I'm equally confused. I'm familiar with the calling party category in >> ISUP, which works only because of the walled-garden nature of the SS7 >> network. Without that, there are really two major factors around this >> which need to be characterized: >> >> 1. Who is authorized to assert a particular calling party category? >> This is much trickier than the identity problem; with >> identity, we >> can trust that a domain is the authority for the use of >> user names >> in that domain. For calling party category, there is no such >> relationship. For example, it would probably not be valid for a >> domain of "adamroach.com" to assert a calling party category of >> "priority," "operator," or "police." >> 2. Under which circumstances is the calling party category required >> to be present? Is there some architectural mechanism that can be >> used to enforce this? (We don't need to define it, but there >> should at least be some idea about whether it's >> possible). If not, >> then there is no purpose in coming up with a protocol mechanism >> for conveying such information. >> >> /a >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Nov 30 22:13:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19005 for ; Tue, 30 Nov 2004 22:13:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZL0s-0003ZR-Mn for iptel-web-archive@ietf.org; Tue, 30 Nov 2004 22:18:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKuT-0004tE-NQ; Tue, 30 Nov 2004 22:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZKpw-0003dB-3L; Tue, 30 Nov 2004 22:07:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18220; Tue, 30 Nov 2004 22:07:21 -0500 (EST) From: Mpierce1@aol.com Received: from [211.239.157.46] (helo=nt37.direct.co.kr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZKvA-0003R3-32; Tue, 30 Nov 2004 22:12:48 -0500 Received: from mail pickup service by nt37.direct.co.kr with Microsoft SMTPSVC; Wed, 1 Dec 2004 12:07:19 +0900 Received: from megatron.ietf.org [132.151.6.71] by mail4.direct.co.kr with ESMTP (SMTPD32-7.15) id A582CB000B8; Wed, 01 Dec 2004 07:34:42 +0900 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZGDa-00073X-TL; Tue, 30 Nov 2004 17:11:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZFE5-0006tR-3R; Tue, 30 Nov 2004 16:07:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06904; Tue, 30 Nov 2004 16:07:54 -0500 (EST) Received: from imo-m15.mx.aol.com ([64.12.138.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFJF-0008Lj-8U; Tue, 30 Nov 2004 16:13:18 -0500 Received: from Mpierce1@aol.com by imo-m15.mx.aol.com (mail_out_v37_r3.8.) id c.74.47df70e2 (3980); Tue, 30 Nov 2004 16:06:13 -0500 (EST) Message-ID: <74.47df70e2.2ede3ac5@aol.com> Date: Tue, 30 Nov 2004 16:06:13 EST Subject: Re: [Sip] RE: [Iptel] Calling Party's Category To: oran@cisco.com, sebastien.garcin@francetelecom.com MIME-Version: 1.0 X-Mailer: 6.0 for Windows XP sub 10500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Content-Type: multipart/mixed; boundary="===============0436617494==" X-OriginalArrivalTime: 01 Dec 2004 03:07:19.0311 (UTC) FILETIME=[DE7B01F0:01C4D752] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: R.Jesske@t-com.net, iptel@ietf.org, taylor@nortelnetworks.com, sip@ietf.org X-BeenThere: iptel@ietf.org 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --===============0436617494== Content-Type: multipart/alternative; boundary="part1_74.47df70e2.2ede3ac5_boundary" --part1_74.47df70e2.2ede3ac5_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 11/30/2004 11:49:18 AM Eastern Standard Time, oran@cisco.com writes: > Also note that if this information is used for any security or > billing-sensitive operations, we have to deal with the issue of how to > secure it against spoofing (SIP UAs are generally not trusted). Would > you believe a call made by Robert Mitnick from a prison phone would > actually have a prison CPC in it's SIP headers :-) ? > Of course, this shows a basic difference in the way this capability is handled in SIP vs today's telephone network. It's an important thing to deal with, since many of these things are mandated by law. For example, I believe the requirement to identify calls from a prison as such is mandated. In today's network, in order to provide assurance that the call is properly marked, not just for CPC but calling party ID as well, the phone in the prison is rnot esponsible for the marking. The switch outside the prison marks any call that comes over that pair of wires. Robert Mitnick had no opportunity to change that marking. The issue for SIP is to provide the same level of assurance for such functions. I'm sure anxious to hear a resolution to this problem, since it keeps coming back. CPC is not unique in this regard, so a general solution is needed. Mike Pierce Artel --part1_74.47df70e2.2ede3ac5_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message=20= dated 11/30/2004 11:49:18 AM Eastern Standard Time, oran@cisco.com writes:


Also note that if this info= rmation is used for any security or=20
billing-sensitive operations, we have to deal with the issue of how to=20
secure it against spoofing (SIP UAs are generally not trusted). Would=20
you believe a call made by Robert Mitnick from a prison phone would=20
actually have a prison CPC in it's SIP headers :-) ?


Of course, this shows a basic difference in the way this capability is h= andled in SIP vs today's telephone network. It's an important thing to deal=20= with, since many of these things are mandated by law. For example, I believe= the requirement to identify calls from a prison as such is mandated.

In today's network, in order to provide assurance that the call is prope= rly marked, not just for CPC but calling party ID as well, the phone in the=20= prison is rnot esponsible for the marking. The switch outside the prison mar= ks any call that comes over that pair of wires. Robert Mitnick had no opport= unity to change that marking.

The issue for SIP is to provide the same level of assurance for such fun= ctions. I'm sure anxious to hear a resolution to this problem, since it keep= s coming back. CPC is not unique in this regard, so a general solution is ne= eded.

Mike Pierce
Artel
--part1_74.47df70e2.2ede3ac5_boundary-- --===============0436617494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0436617494== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0436617494==--