From owner-pint-outgoing@lists.research.bell-labs.com Thu Jun 3 12:03:35 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07609 for ; Thu, 3 Jun 1999 12:03:34 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 9BB5152B6; Thu, 3 Jun 1999 10:36:00 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0675552D5; Thu, 3 Jun 1999 10:35:59 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-ID: <000801bea909$bb7ec600$1501a8c0@LarsAndersen> From: "Lars Balle Andersen" To: Subject: subscribe Date: Fri, 28 May 1999 08:58:04 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01BEA8E8.328F8C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BEA8E8.328F8C60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0005_01BEA8E8.328F8C60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0005_01BEA8E8.328F8C60-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Tue Jun 8 05:04:41 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22129 for ; Tue, 8 Jun 1999 05:04:37 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 306E052DC; Tue, 8 Jun 1999 04:57:28 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F131752DD; Tue, 8 Jun 1999 04:57:26 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Date: Tue, 08 Jun 1999 11:53:20 +0300 From: Khaled Elsayed Subject: IEEE Communications Magazine: Call for Papers To: khaled@ieee.org, Laurent.Toutain@enst-bretagne.fr Message-id: <375CDA00.2987C112@ie-eg.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win95; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Call for Papers IEEE Communications Magazine Internet Technology Series Series Editors Laurent Toutain (ENST Bretagne) and Khaled Elsayed (Cairo University) The IEEE Communications Magazine invites contributions from authors with academic and industrial affiliation for the Internet Technology Series. The Focus of the Internet Technology Series is to bring the latest advances in state of the art techniques in the Internet to the large readers group of the Communications Magazine. Preference will be given to papers addressing technical issues that are encountered in implementing current or future Internet products or solutions. We are currently looking for articles in the following areas: - Web Caching (centralized and distributed) - Internet Telephony, VoIP, SS7 Gateways - DiffServ Model and Implementations - MPLS Deadline for submission: August 1, 1999. ======================= The coming issue of the Internet Technology Series is scheduled for January 2000 (an extremely attractive date, isn't it?). In order for us and the editorial office to process the review process and afterwards the accepted papers, you must submit your paper by the above deadline. However, we will continue to process papers all year round for forthcoming issues. Article Style Information ========================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the article. Articles may be edited for content, and will be copyedited for compliance with the magazine's style guidelines. Page proofs will be sent to the contact author for final review prior to publication. Mathematical equations should not be used unless they are vital to the presentation. Even then, they should be kept to a minimum. If the article has numerous equations, please contact the editor handling the manuscript. References should be included only to guide readers to more information on the topic; the reference list should not include every available source (a limit of ten references is recommended). Use footnotes only where necessary. Articles should not exceed 4500 words. Figures and tables should be limited to a combined total of six. If the article exceeds these recommended limits, please contact the editor handling the manuscript. Also check: http://207.127.135.8/ci1 (author guidelines) and http://207.127.135.8/ci1/public/1998/may/cimess.html Since this is an Internet related series, we would like to handle all the submissions and the reviewing process via the Internet. Please send your submission in postscript or PDF (acrobat) format to the series editors. Khaled Elsayed: Khaled@ieee.org Laurent Toutain: Laurent.Toutain@enst-bretagne.fr --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Fri Jun 11 07:36:54 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27767 for ; Fri, 11 Jun 1999 07:36:54 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id A7DD252EF; Fri, 11 Jun 1999 06:31:20 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 237CA52F0; Fri, 11 Jun 1999 06:31:20 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-Id: From: Peter.Kutschera@arcs.ac.at To: igorf@holta.ho.lucent.com Cc: pint@lists.research.bell-labs.com Subject: Re: PINT Implementations Date: Fri, 11 Jun 1999 12:29:05 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Dear Mr. Faynberg! On Mon, 29 Mar 1999 you asked for feedback from PINT implementers. For a report I am just writing I would need to know if someone and, if so, who is implementing PINT services. Can you please share your experience with me? Any comments are wellcome. Thanks Peter Kutschera, Austrian Research Center Seibersdorf http://www.arcs.ac.at http://enviro.arcs.ac.at/kutschera/ --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Fri Jun 11 16:26:03 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06903 for ; Fri, 11 Jun 1999 16:26:02 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 33D7552F3; Fri, 11 Jun 1999 15:28:19 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 80A1552F4; Fri, 11 Jun 1999 15:28:18 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com From: faynberg@lucent.com (Igor Faynberg) Date: Fri, 11 Jun 1999 15:27:50 -0400 Message-Id: <199906111927.PAA28014@holta.ho.lucent.com> Original-From: igorf@holta.ho.lucent.com (Igor Faynberg) To: Peter.Kutschera@arcs.ac.at Cc: pint@lists.research.bell-labs.com Subject: Re: PINT Implementations Content-Type: text Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Dear Mr. Kutshera, Thank you for your interest in PINT implementations. These are taking place in several companies; of these, Siemens and Lucent Technologies made official announcements to that end. We are, indeed, going to discuss PINT implementations soon. At the moment, the PINT Protocol editors are putting final touches to the RFC-to-be, with the concentration on security. Sometime next week, the final copy, which will then be sent for the last call, will be published. Once the protocol is frozen, it will make sense to discuss the implementations, so I do hope we will see the implementations reports starting in August of these year. By "seeing" I mean seeing them posted to PINT. Until then, I think it would be inappropriate for me or anyone else to use this list as some sort of advertisement for company products. But I invite all those who have implemented the present version of PINT to respond do your query privately. With best regards, Igor Faynberg --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Sat Jun 12 11:31:01 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29042 for ; Sat, 12 Jun 1999 11:31:00 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 14D6852EF; Sat, 12 Jun 1999 11:27:24 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 76F9852F5; Sat, 12 Jun 1999 11:27:23 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com X-Sender: lwc@derek.roke.co.uk (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 12 Jun 1999 16:26:26 +0100 To: pint@lists.research.bell-labs.com, owner-confctrl@ISI.EDU From: lwc@roke.co.uk (Lawrence Conroy) Subject: SIP telephone-subscriber in PINT/SDP? Cc: scott.petrack@metatel.com Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Dear All, First, apologies for the cross-posting; this is part of PINT, but may have an impact on SDP implementations. The current Spec for PINT uses a subset of the SIP telephone-subscriber address format within its Session Description (one that allows only digits and "-" separators, with or without a leading "+"). What I am unsure about is whether or not allowing a "full" SIP telephone-subscriber format (as in RFC2543, Figure 4) will break existing SDP parsers. If there's some horrible consequence that anyone can see, PLEASE enlighten me before we put the PINT draft to bed. If no one hollers now, I'll change the PINT draft to just use the SIP definition, as we've received a request to handle DTMF-digit characters like "*" and "#". All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd charge you for them"| |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Mon Jun 21 06:58:47 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02959 for ; Mon, 21 Jun 1999 06:58:46 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2CA0752D5; Mon, 21 Jun 1999 06:55:19 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6FCAD52DB; Mon, 21 Jun 1999 06:55:18 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-Id: <199906211054.LAA19698@teltec.dcu.ie> From: "Rob Brennan" To: Subject: A couple of editorial comments on PINT draft Date: Mon, 21 Jun 1999 11:48:17 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1154 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, while reading the draft I think that I noticed two minor glitches: 1. page 8, paragraph 3 replace reference to "Service Gateway Control Function" with "Service Control Gateway Function" 2. page 44, section 6.5.2 replace reference to "Request-to-Talk" service with "Request-to-Call" best regards Rob Brennan, Research Officer, Teltec DCU Phone: + 353 1 704 5853 --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Wed Jun 23 11:25:03 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02227 for ; Wed, 23 Jun 1999 11:25:03 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 303D652B6; Wed, 23 Jun 1999 11:19:19 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 981A652DB; Wed, 23 Jun 1999 11:19:18 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Date: Wed, 23 Jun 1999 11:18:27 -0400 (EDT) From: Scott Petrack To: "Adam B. Roach" Cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com Subject: Re: SUBSCRIBE/NOTIFY In-Reply-To: <199906221842.NAA16470@b04a24.exu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Yes, there is specification of it in the PINT draft , to be used by a PINT client to get notifications about the changing state of a PSTN phone call. Scott On Tue, 22 Jun 1999, Adam B. Roach wrote: > > Is there any ongoing work to extend the S U B S C R I B E/NOTIFY mechanism > for anything beyond presence? > > There have been numerous discussions over the past several months > about the use of these methods for requesting DTMF information and > other call-trigger type events, but I believe the desired balance of > complexity with flexability hasn't been determined yet. > > If anyone intends to submit a draft relating to these issues > in time for the Oslo meeting, I'd appreciate knowing. Thanks. > > P.S. I've tried posting on this topic several times over the past > week, and have come to beleive that the mailer at isi.edu has > been programmed to silently drop messages with the word > "S U B S C R I B E" in them (hence the spaces). > > -- > Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 > adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA > --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Fri Jun 25 17:11:29 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05371 for ; Fri, 25 Jun 1999 17:11:28 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 0ED6D52DF; Fri, 25 Jun 1999 17:07:05 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6787352DB; Fri, 25 Jun 1999 17:06:59 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Cc: pint list , Steve Bellovin , Igor Faynberg Message-ID: <3773E1A1.E50292DD@lucent.com> Date: Fri, 25 Jun 1999 16:08:02 -0400 From: Alec Brusilovsky Reply-To: abrusilovsky@lucent.com Organization: Lucent Technologies, Bell Laboratories Innovation X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: pin list Original-CC: pint list , Steve Bellovin , Igor Faynberg Subject: Proposed PIN Charter Content-Type: multipart/mixed; boundary="------------3B892170140719931602CBF8" Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --------------3B892170140719931602CBF8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please see proposed PIN Charter attached here for discussion on the PIN list. Regards, Steve Bellovin Alec Brusilovsky ****************************** Description of Working Group: The PSTN/Internet Notification (PIN) WG addresses how services supported by IP network entities can be started from PSTN requests, as well as the connection arrangements through which PSTN (Public Switched Telephone Network) can request actions to be carried out in the IP-network in response to events occuring within the PSTN. The parameters passed in any PIN Service request will, of course, be limited to information available within the PSTN. Definition of any information or data within PSTN is the responsibility of the ITU-T and so is out of scope of this WG. An example of such a service is Internet Call Waiting that, on an incoming PSTN call, asks IP nodes to carry out some actions. This working group has the following main objectives: * Study architecture and protocols needed to support services requested by PSTN entities to be carried out by IP network nodes. The protocols must carry securely PSTN requests to the IP network, and responses back to the PSTN. * The target of this working group is to describe building blocks for PSTN-IP services that start from PSTN requests, and not to standardize the PSTN-IP services themselves. Specific services to be considered initially are: 1. Internet Call Waiting 2. Internet Caller-Id Delivery 3. Internet Call Forwarding and "Follow Me". * Produce an Informational RFC that describes current practices for supporting the services in question. * Based on the existing practice and agreed on improvements, develop a Standards Track RFC that specifies a protocol by which PSTN Intelligent Network Service Nodes (or any other node that implements the Service Control Function) can request services of IP hosts, and by which status indications can be returned to the PSTN. * Consider security issues relating to providing functions of this type. In particular understand any threats posed by this technology and address them, and any other security issues, in the proposed standard. * Based on the existing practice and agreed on improvements, develop a standards track RFC for a relevant MIB (PIN MIB) to support the service management protocol between Internet applications and the PSTN Service Management System. The MIB is to conform to SNMP standards. * Consider extensions of the above architecture and protocols to support a wider range of PSTN Intelligent Network (IN) and IP based services. * PIN WG will collaborate with other IETF WG's, working on similar issues and having expertise in PSTN/IP interworking (IPTEL, MMUSIC, PINT). PIN WG will, also, establish rational cooperation with other relevant standard bodies (ITU-T SG11). --------------3B892170140719931602CBF8 Content-Type: text/plain; charset=us-ascii; name="PIN Charter.txt" Content-Disposition: inline; filename="PIN Charter.txt" Content-Transfer-Encoding: 7bit Description of Working Group: The PSTN/Internet Notification (PIN) WG addresses how services supported by IP network entities can be started from PSTN requests, as well as the connection arrangements through which PSTN (Public Switched Telephone Network) can request actions to be carried out in the IP-network in response to events occuring within the PSTN. The parameters passed in any PIN Service request will, of course, be limited to information available within the PSTN. Definition of any information or data within PSTN is the responsibility of the ITU-T and so is out of scope of this WG. An example of such a service is Internet Call Waiting that, on an incoming PSTN call, asks IP nodes to carry out some actions. This working group has the following main objectives: * Study architecture and protocols needed to support services requested by PSTN entities to be carried out by IP network nodes. The protocols must carry securely PSTN requests to the IP network, and responses back to the PSTN. * The target of this working group is to describe building blocks for PSTN-IP services that start from PSTN requests, and not to standardize the PSTN-IP services themselves. Specific services to be considered initially are: 1. Internet Call Waiting 2. Internet Caller-Id Delivery 3. Internet Call Forwarding and "Follow Me". * Produce an Informational RFC that describes current practices for supporting the services in question. * Based on the existing practice and agreed on improvements, develop a Standards Track RFC that specifies a protocol by which PSTN Intelligent Network Service Nodes (or any other node that implements the Service Control Function) can request services of IP hosts, and by which status indications can be returned to the PSTN. * Consider security issues relating to providing functions of this type. In particular understand any threats posed by this technology and address them, and any other security issues, in the proposed standard. * Based on the existing practice and agreed on improvements, develop a standards track RFC for a relevant MIB (PIN MIB) to support the service management protocol between Internet applications and the PSTN Service Management System. The MIB is to conform to SNMP standards. * Consider extensions of the above architecture and protocols to support a wider range of PSTN Intelligent Network (IN) and IP based services. * PIN WG will collaborate with other IETF WG's, working on similar issues and having expertise in PSTN/IP interworking (IPTEL, MMUSIC, PINT). PIN WG will, also, establish rational cooperation with other relevant standard bodies (ITU-T SG11). --------------3B892170140719931602CBF8 Content-Type: text/x-vcard; charset=us-ascii; name="abrusilovsky.vcf" Content-Description: Card for Alec Brusilovsky Content-Disposition: attachment; filename="abrusilovsky.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Brusilovsky;Alec x-mozilla-html:FALSE org:Lucent (jg7290000) version:2.1 email;internet:abrusilovsky@lucent.com title:MTS tel;fax:+1 630 713 5840 tel;work:+1 630 713 8401 adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S x-mozilla-cpt:;0 fn:Alec Brusilovsky end:vcard --------------3B892170140719931602CBF8-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Fri Jun 25 21:04:31 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09126 for ; Fri, 25 Jun 1999 21:04:30 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 933F452DC; Fri, 25 Jun 1999 20:59:20 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0C10D52DD; Fri, 25 Jun 1999 20:59:19 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com X-Sender: lwc@derek.roke.co.uk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 26 Jun 1999 01:58:41 +0100 To: "Adam B. Roach" From: lwc@roke.co.uk (Lawrence Conroy) Subject: Re: PSTN Interworking Draft Cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk At 9:44 am 25/6/99, Adam B. Roach wrote to the MMUSIC list: >The following draft is now available from the Internet Drafts >archive: >"SIP PSTN Interworking Umbrella 'Require:' Header" > This document outlines a new value for the SIP "Require:" header > which denotes compliance with a number of mechanisms necessary to > interwork smoothly with existing telephony networks. > To which I reply: I have a slight qualm with this document. The PINT Drafts have had two methods called SUBSCRIBE and NOTIFY for a long while now (basically since Henning and Jonathon originally suggested them to us when what is now IMPP started). I HOPE that the SUBSCRIBE/NOTIFY stuff of section 2.4 (with the note "This document is not yet written.") isn't going to clash with the existing PINT use, otherwise we'll break things (I trust that isn't the intent :). A similar approach seems likely in any PIN work, and any revivification of the SIP-for-Presence work. Any new document is not going to hit an empty table. All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd charge you for them"| |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Sat Jun 26 13:36:43 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05937 for ; Sat, 26 Jun 1999 13:36:42 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 194BA52DD; Sat, 26 Jun 1999 13:31:21 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6744452E0; Sat, 26 Jun 1999 13:31:20 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com From: Sean Olson Date: Sat, 26 Jun 1999 12:30:31 -0500 (CDT) Message-Id: <199906261730.MAA05350@b04a45.exu.ericsson.se> To: Adam.Roach@ericsson.com, lwc@roke.co.uk Subject: Re: PSTN Interworking Draft Cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk > > At 9:44 am 25/6/99, Adam B. Roach wrote to the MMUSIC list: > >The following draft is now available from the Internet Drafts > >archive: > >"SIP PSTN Interworking Umbrella 'Require:' Header" > > This document outlines a new value for the SIP "Require:" header > > which denotes compliance with a number of mechanisms necessary to > > interwork smoothly with existing telephony networks. > > > > To which I reply: > I have a slight qualm with this document. The PINT Drafts have had two > methods called SUBSCRIBE and NOTIFY for a long while now (basically since > Henning and Jonathon originally suggested them to us when what is now IMPP > started). > > I HOPE that the SUBSCRIBE/NOTIFY stuff of section 2.4 (with the note "This > document is not yet written.") isn't going to clash with the existing PINT > use, otherwise we'll break things (I trust that isn't the intent :). A > similar approach seems likely in any PIN work, and any revivification of > the SIP-for-Presence work. Any new document is not going to hit an empty > table. > > All the best, Lawrence > ----------------------------------------------------------------------- > | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | > | Roke Manor Research | were my Company's they'd charge you for them"| > |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| > The intent of the document was not to re-invent anything but to bring the various drafts concerning PSTN-SIP interworking under one umbrella draft to simplify the development and standardization of SIP nodes which must interwork with the PSTN. Whatever SUBSCRIBE/NOTIFY methods can be agreed upon and standardized will be used. (Whether from PINT, PIN, IMPP or MMUSIC) ----------------------------------------------------------------- Sean Olson E-mail: sean.olson@ericsson.com Ericsson Inc. Voice: (972) 583-5472 FAX: (972) 669-0154 --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Tue Jun 29 09:02:25 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10286 for ; Tue, 29 Jun 1999 09:02:24 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id 2D5F352DF; Tue, 29 Jun 1999 08:57:53 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 58C2452D5; Tue, 29 Jun 1999 08:57:49 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Cc: pint list Message-ID: <3778B482.14E9D50@lucent.com> Date: Tue, 29 Jun 1999 07:56:51 -0400 From: Alec Brusilovsky Reply-To: abrusilovsky@lucent.com Organization: Lucent Technologies, Bell Laboratories Innovation X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: pin list Original-CC: pint list Subject: PSTN Internet Notification (PIN) Framework I-D is available Content-Type: multipart/mixed; boundary="------------338156E83A69066CED83FF4D" Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --------------338156E83A69066CED83FF4D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please note: PSTN Internet Notification (PIN) Framework Internet-Draft is available from the official IETF directory at: http://search.ietf.org/internet-drafts/draft-brusilovsky-pin-framework-00.txt Regards, Alec Brusilovsky --------------338156E83A69066CED83FF4D Content-Type: text/plain; charset=iso-8859-1; name="draft-brusilovsky-pin-framework-00.txt" Content-Disposition: inline; filename="draft-brusilovsky-pin-framework-00.txt" Content-Transfer-Encoding: 8bit PSTN Internet Notification (PIN) Framework [Page 1] A. Brusilovsky Internet Draft J. Buller L. Conroy V. Gurbani L. Slutsman Expires: December 1999 PSTN Internet Notification (PIN) Architecture, Services and Protocols (A Provisional Framework) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The purpose of this Internet Draft is to continue discussion on the issues involved in PSTN Internet Notification (PIN), as part of interconnecting IP and Public Switched Telephone Network (PSTN) with the intent of converging existing and creating new hybrid PSTN and IP services. PSTN initiated Service Requests, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an Informational RFC. The rest of this document is as follows: Section 2 briefly describes the PIN concept. June 1999 PSTN Internet Notification (PIN) Framework [Page 2] Section 3 addresses Pre-PIN services and implementations. Section 4 gives comparative analysis of PINT and PIN architecture, focusing on similarities and differences of PINT and PIN architecture. Section 5 describes the scope of the proposed project by introducing its overall architecture, identifying the interfaces to be standardized and specifying the terminology definitions. Section 6 addresses PIN Protocol profile. Sections 7, 8, and 9 respectively address security considerations, supply references, and provide the authors addresses, as required by [11, 12]. Section 10 acknowledges individuals providing assistance in the creation of this document. 2. PIN Description The current PSTN/Internet Interfaces (PINT) WG addresses connection arrangements through which Internet applications can be used to enrich PSTN (Public Switched Telephone Network) telephony services. Some Interworking services require requests for services that come from the PSTN/IN. Essentially, these requests will be a "mirror image" of PINT requests. To provide interworking between PSTN and IP networks, it is very useful to use notifications of events happening within the PSTN to generate service requests that may then be passed on to the IP network for execution. This next section describes the kinds of events within the PSTN which initiate the process that results in making IP network service requests. It is included for information; this behavior does not have a direct impact on any resulting IP network protocol, giving only the reasons why an IP protocol exchange may be initiated. 2.1 PSTN/IN Events and Procedures PSTN/IN Call Flows are organized around actions or collections of actions called Point-In-Call (PIC). Detection Points (DPs), which are associated with the PICs, operate between the PICs, and can be the basis that can in turn be used to generate service requests for the IP network. IN furnishes "Network Intelligence" to the PSTN. Similarly, it can be utilized to initiate Service Requests to the IP network. There is an June 1999 PSTN Internet Notification (PIN) Framework [Page 3] important difference between the IN and IP: while a PSTN switch, designed to support IN PICs and DPs, can send messages to IN (this is because of the high performance of the dedicated SS7 network and associated protocols), it is highly unlikely, for reasons of cost, performance and security, that a PSTN switch will be able to exchange messages with the IP network. It is more realistic to use the SCP as the contact point with IP. In certain cases, for example (PSTN to PSTN transport via IP backbone with MEGACO Call Controller and SIGTRAN transport protocol) the Call Controller can talk to the PSTN. For that kind of architecture, it is possible to use call signaling messages/events such as Off-hook, On-hook directly for the IP interaction. As in the PINT milestone services [1], PIN studies atomic actions. These may be utilized as explicit services in their own right, as well as building blocks in the realization of more complex services. PINT and PIN complement each other, providing developers with a comprehensive set of "LEGO" type building blocks for these complex services that can deal not only with IP-initiated services in PSTN networks [1], but, also, with PSTN-initiated services in IP networks. Examples of services that that may be realized by these building blocks are: 1. Internet Call Waiting (ICW). ICW is the capability to provide incoming call notification and completion options when the Subscriber is on a dial-up IP connection [8]. 2. Internet Call Management. PSTN call notification and control options (flexible call screening, forwarding, etc.), delivered to an IP client [8]. 3. Internet Conference Management. PSTN Teleconference notification and management from an IP Client [6]. 4. Internet Conference Mediation. Pre-Teleconference (before an actual connection is made) management service from an IP client. 5. Advanced Caller ID Delivery [4]. Ordered incoming call notification to multiple Subscriber's dial-up IP connections. 6. Queue Management. Notification of the status and events of the call queue, much needed for the IP-based Automatic Call Distribution and Call Center applications [5]. June 1999 PSTN Internet Notification (PIN) Framework [Page 4] 7. Internet Call Routing (ICR). Flexible routing and control over a dial up PSTN call from an IP host. 8. Hybrid Network ACD [9] 3. Pre-PIN services and implementations. 3.1 Internet Call Waiting (ICW). Providing incoming call notification and completion options when the Subscriber is on a dial-up IP connection - Lucent [8]. Service Description When a call attempt is made to a service Subscriber who is presently on a dial up connection, they (the service Subscriber) are presented with a pop-up dialog box, that presents the caller's number and, optionally, his or her name. Internet Call Waiting solution provides a simple, graphically-oriented way to notify subscribers while connected to the Internet, of incoming calls. It allows the subscriber to accept or reject the call. Service providers can achieve the following important benefits through the use of Internet Call Waiting Service: o More calls completed. Call completion is an important aspect of the service provided by telecommunication operators. Calls that end in busy or no- answer, consume network resources. Solution like Internet Call Waiting contributes to greater call completion which lowers expense and provides value to both the consumer and service provider. o The ICW platform is the foundation to offer services: The service provider has the opportunity to enhance Internet Call Waiting with other services like Internet Follow-me, personalized call management, unified messaging service, click to return (dial) an important call, and other call management functions which integrate voice and data services. o Service providers can offer the following important benefits to subscribers through the use of Internet Call Waiting Service: � Simple way to manage voice and data calls over a single telephone line. � Ability to track all incoming calls while the service is active. � PC Graphical Subscriber Interface provides a simple intuitive Subscriber interface and also allows easy customization. June 1999 PSTN Internet Notification (PIN) Framework [Page 5] When the Calling Party dials the ICW Subscriber's Destination Number, the Calling Party experiences the standard Call Waiting treatment, ringing, until Calling Party abandons or the Subscriber specified treatment. Subscriber treatment options and Calling Party experience are: o Refuse Call: Calling Party hears ringing until Calling Party abandons. o Hold Call: Calling Party hears [optional] announcement to hold while "other" call in progress is completed. The intent is that the Subscriber will accept the call momentarily. o Send to Voice Mail/third party number. Calling Party hears voice mail system announcements. o Accept Call: Calling Party hears ringing until they connected to the Subscriber. 3.2 Call Completion Internet Busy (CCIB) - Siemens. 3.2.1 Service Description The CCIB service allows subscribers to determine completion actions for telephony calls to a number which is currently in use (because the subscriber is logged on to the Internet) using the proposed PINT and PIN protocols. Completion actions could be, for example: o Refuse the call. o Forward the call to Voice Mail. o Forward the call to another number. o Drop Internet connection and take the telephony call. o Establish VoIP connection on terminating side to take the call. o Take details of the callee for later connection. o Take a voice message which can then be relayed to the terminating ends device. In an implementation of this service the subscriber would register for this service using the PINT protocol each time they wished to receive messages. This could be each time they log onto the Internet. This registration is stored either within the Internet or the PSTN/IN domains for later reference by a PIN CCIB service. Note that this mechanism inherently provides mobility as the June 1999 PSTN Internet Notification (PIN) Framework [Page 6] subscriber may register their location on any number. The registration process could be undertaken either : 1) With the help of the underlying PINT executive system providing the actual telephony number. 2) By the register message containing the telephony number. It is accepted this scenario has inherently greater security implications, which will need to be resolved during any implementation. Upon successful registration a 'thin' PIN server is activated, or downloaded to and then activated on, the subscriber's machine. When a call attempt is made to the telephony number on which the subscriber has registered their current connection to the Internet, the PSTN/IN detects this. Upon such a call attempt detection the PSTN/IN PIN gateway issues an invitation to the subscriber to take the call. The 'thin' PIN server on the subscribers machine receives the invitation and allows the subscriber to decide (from the list of possible options indicated above) how to handle the call. This choice is relayed in a response to the invitation in order that the PSTN/IN can act upon the subscriber's choice. 3.3 Advanced Caller ID Delivery - AT&T [7]. 3.3.1 Service Description The "Advanced Internet Caller-ID Delivery" service described, we envision being owned by a long-distance carrier provider (LDCP) such as AT&T, to which we refer as the service provider (SP). The subscriber to the service may have one or more Internet accounts (at home, at the office, etc.) and one or more telephone numbers on which they may be reached. One telephone number (normally a residential number) will be designated as the Primary Telephone Number (PTN). The PTN must be registered with the SP, and the table of alternative telephone numbers (in the order desired) will be stored in the SCP database where the PTN is the primary key. When the PTN is dialed, the list of provided telephone numbers is retrieved from the SCP, and the service performs the following steps: o Each provided telephone number, starting with the PTN is dialed. A line is considered to be unavailable if the call is not answered after a specified number of rings. o The call will be connected to the first available line. o Otherwise, the SCP sends a notification to the IP domain and June 1999 PSTN Internet Notification (PIN) Framework [Page 7] terminates the incoming call. o Each IP account is analyzed to determine whether the subscriber is on-line. If they are, a pop-up window will appear on the screen with the "clickable" Caller-ID number; therefore, the subscriber may input a phone number to receive the call and then click-to-dial the Caller-ID number. o Otherwise, if the subscriber is not on the Internet, they will be sent the email with the Caller-ID and the time of the call. 4. Similarities and differences of PIN and PINT architecture. Just like in PINT, as described in [1], in which the PINT protocol is a protocol between PINT Client and PINT Gateway (server), the PIN protocol addresses the interface between the PIN Executive System and IP-based PIN Servers. Unlike PINT, the PIN Executive System acts as a client, generating requests to be sent to the PIN Servers. It is useful to consider, in the first instance, how a PIN protocol would exist in relation to the work presently being undertaken with the PSTN/Internet Interfaces (PINT) WG. The PINT WG addresses connection arrangements through which Internet applications can request and enrich PSTN (Public Switched Telephone Network) telephony services. As such the PIN WG aims to perform a similar function in reverse, namely; address the connection arrangements through which the PSTN/IN can request and be enriched by services executing in the Internet domain. Figure 1. details this relationship schematically. PINT deals with requests for a service within the PSTN/IN domain and receives responses back from the PSTN/IN domain. PIN deals with requests from the PSTN/IN domain for a service in the Internet domain and receives responses back from the Internet domain. 5. Proposed Architecture. With the proliferation and wide acceptance of the Internet, and more so with the convergence of the Internet and PSTN, there is an increasing desire for events occurring on the PSTN domain to be propagated to the Internet domain. The PIN protocol attempts to fill this void. Entities in the Internet domain can receive the events generated by the PSTN domain and act appropriately. Since the PIN BOF the PIN architecture is often thought of as a mirror image of the PINT architecture and, we think, there is some truth in this statement. The basic motivation for PINT is to invoke telephony services from the Internet. To implement this the following June 1999 PSTN Internet Notification (PIN) Framework [Page 8] chain of events should take place: o an IP host sends a request to a server on a boundary of an IP network (PINT Gateway); o the Gateway relays the request to a telephone network, more precisely, to a PSTN Intelligence Node(SCP or Service Node) ; o triggered by this request, the intelligence node executes the service logic that controls the PSTN Switches that in turn carry out the desired telephony service. In the proposed PIN scenario the PSTN requests an entity in the Internet domain to carry out certain Internet based services (normally these services will involve interactions with Internet hosts and Gateways). The generic scenario is as follows: o a PSTN host (switch) triggers the execution of the service logic in a PSTN Intelligent node (Requesting System) on the boundary of PSTN and IP domains; o at a certain point of executing the service program, the PSTN Intelligence node (Requesting System) sends a request to the Internet (using protocol A in Figure 1, which is outside of the scope of this WG) PIN Executive System. o triggered by this (PSTN) request, the PIN Executive System invokes some service logic (q.v.) that instructs (using the PIN protocol) the PIN servers to carry out the desired PIN service. While we defer the discussion of PIN "milestone services" for later, one point may be made: these services do not have to mimic the telephony primitives like Call Forwarding, Call Waiting, etc. The PIN architecture is depicted in Figure 1. Certain basic call and connection events are detected at armed DPs and become visible to the IN service logic. The IN service logic program in the PSTN Requesting System identifies the need to request an Internet (PIN) service. As previously stated. protocol A in Figure 1 is outside of the scope of this WG. The specifications of protocol A may be better addressed in ITU-T. These requests are sent to the PIN Executive System. The PIN Executive System executes the appropriate service logic program; the program, acting as a PIN Client, communicates with appropriate PIN Servers. PIN requests may pass through zero or more PIN servers to take advantage of location service, redirection, and registration capabilities of the PIN protocol. The comparison of PIN and PINT architectures, depicted in Figure 1, June 1999 PSTN Internet Notification (PIN) Framework [Page 9] demonstrates the similarity and symmetry between PIN and PINT and reveals the data flows 5.1 Terminology definitions. This section provides more detailed definitions of the terminology used in this document. Service: A high level behavior performed within either the PSTN/IN, Internet or in conjunction in both domains. This behavior incorporates, as part of its expression, PINT and/or PIN protocol message flows, between these domains, in order to achieve the objectives of its function. Requesting Entity/Requestor: The entity (either a user or the equipment and programs that act as their agent) that constructs and sends a message requesting some action on the part of the recipient. In the context of PIN, the Requesting Entity is usually a component within the PSTN/I.N., and the recipient will be an Executive System (q.v.) within the IP network. Executive System: The entity that performs actions. In the PIN context, this entity will exist within the IP network, and will execute these actions in response to requests it receives from an entity within the PSTN/I.N. Requesting System: The entity that performs actions on behalf of PSTN/IN. In the PIN context, this entity will exist within the PSTN/IN network, and will execute these actions in response to requests it receives from the PSTN/I.N. Invocation/Request: The procedure by which a Requesting Entity can ask for an action to be executed by another (Internet Intelligence Node) entity. In the case of PIN, the Request will be initiated from a PSTN/I.N. entity, and the resulting action will be executed by an IP network entity. Reply/Response: The procedure by which an entity that has received a prior request for action can return information on the status of that request, or the disposition of the requested action. In the case of PIN, the Response will be generated by the IP Network-based PIN Gateway that received a request, and will be returned to the Requesting Entity within the PSTN/I.N. Service Subscription: The procedure by which a Requesting Entity can request (and gain approval for) the right to send subsequent Invocations of June 1999 PSTN Internet Notification (PIN) Framework [Page 10] particular actions. Note that this procedure may be implicit; there may not be a need for prior subscription for some requests, whilst for others there may be a required "pre-service" procedure (such as setting up accounts and security relationships). Service Unsubscription: The procedure by which a Requesting Entity can request that any long term relationship entered into by means of a prior subscription be dissolved. There can be many reasons for taking this step; for example, a recurring charge might be applied for the period of a subscription, or it may be that a subscriber is not going to be in a position to make requests (such as no longer having an appropriate terminal). Note that there can be circumstances in which the entity with which the subscription has been made is no longer willing to maintain the relationship with the subscriber (for example, on non payment, or usage breaches). As such, the "subscribee" may inform the subscriber that their relationship has been dissolved. In other words, subscription requests are said to be idimportant. Service Activation/Enabling: The procedure by which a Requesting Entity can inform the recipient that it is now willing to engage in transactions associated with a long term relationship to which it has previously subscribed. Service Deactivation/Disabling: The procedure by which an Requesting Entity can inform the recipient that it is temporarily unwilling to engage in transactions associated with a relationship to which it has previously subscribed. Registration of Interest (in an event or entity status or service status or disposition): The procedure by which a Requesting Entity can ask to be informed of events that occur in the domain of the recipient of this request. The events of interest can be classified in a number of ways. They may constitute changes of status of an Invoked Action, or in its disposition on completion, or in the status of some entity with which an Invocation association is not directly in place (e.g. the appearance of a user on the IP network, or their availability). This procedure can be considered to open a monitoring relationship between the requesting entity and the entity receiving the request. Where the events of interest involve other entities in addition to the receiving entity, then this will act as the representative; any procedure needed for it to glean information on the events of interest is hidden. June 1999 PSTN Internet Notification (PIN) Framework [Page 11] Notification/Indication: The procedure by which an entity that has received a prior registration of interest can inform the requesting entity of the events for which it has asked to be notified. 6. PIN Protocol profile At this early stage it is felt that there is some merit in abstraction away from explicit message flows (and their potential contents) to be used in the provision of services. We shall initially identify the atomic actions between each domain, which could be required to provide a basis for the production of practical services. There are five such generic actions, which could exist in order to provide the proposed services. These are : 1) Initiation actions. A request is sent from one domain to the other to initiate a service in that domain. In the case of PIN this request is sent from the PSTN/IN domain to Internet domain. A response message is returned to indicate the status or disposition of this requested action. 2) Data set action. A message is sent from one domain to the other which contains information, which should be stored in the other domain. 3) Data request action. A message is sent which requests information held in the other domain. This data is returned in the response message. 4) Subscription to/or Registration of interest action. A message is sent from one domain to another to request that an entity in the subscribing domain (PSTN/IN in the PIN case) be informed in the event of some future change in state of some entity in the other domain (Internet in the PIN case). 5) Notification action. A notification message is sent from the domain where a change in state of some entity has occurred, to the entity in the other domain, which has expressed an interest (via a subscription/registration mechanism) in these events. Note that a Notification is only sent within the context of a monitoring relationship that has been opened by prior EXPLICIT registration of interest; there should therefore exist NO possibility of an 'unsolicited' notification message being sent. Some readers may consider the actions described above to themselves June 1999 PSTN Internet Notification (PIN) Framework [Page 12] be 'services'. In the interests of clarity the term 'service' is defined as in the terminology section. 7. Security Considerations PIN Security Requirements are much more stringent than those in PINT. The reason for this is twofold: o A subscriber has to prove their "ownership" of a specific telephone line. This is important for privacy reasons. Unauthorized entities should know as little as possible about the activities on the subscriber's line. o The subscriber has to prove some ownership of their IP addresses (this is complicated because of the transient nature of the IP address, especially for dialup clients, while PIN requests may persist). Two questions should be asked: when a PIN server should stop sending messages to a particular, and possibly stale, IP address?; should the PIN messages be encrypted to protect the privacy of the client from the next 'owner' of the IP address? On the other hand there are PIN services that may have a similar security model to PINT. For such services the requirements stated in [1] should apply. o Peer entity authentication to allow a communicating entity to prove its identity to another in the network. o Non-repudiation to account for all operations in case of doubt or dispute. This could be achieved by logging all the information pertinent to the transaction. In addition, the PSTN network will maintain its own account of the transaction for generating bills. o Confidentiality to avoid disclosure of information without the permission of its owner. Although this is an essential requirement, it is not particular to the proposed project. o PIN Client profile verification to verify if the end user is authorized to use a service. In the course of the project execution, additional requirements are likely to arise and many more specific security work items are likely to be proposed and implemented. Some of the PIN-specific security considerations: o Cracking is a threat to any Service Provider (PSTN, Intranet, Internet). It is real danger - phone companies are common targets o Notification spoofing is one of the threats June 1999 PSTN Internet Notification (PIN) Framework [Page 13] o Existing mechanisms applied to the Internet can be implemented o Stealing a Notification is a new type of security threat 8. References [1] S. Petrack & L. Conroy, " The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services" Internet Draft, Internet Engineering Task Force, June 1999. [2] M. Handley, E. Schooler, H. Schulzrinne, & J. Rosenberg, "SIP: Session Initiation Protocol", RFC2543, Internet Engineering Task Force, March 1999. [3] H. Lu et al, "Inter-Networking--Pre-PINT Implementations", Informational RFC2458, Internet Engineering Task Force, Nov 1998. [4] L. Slutsman, "Advance Internet Caller-ID Delivery Service" Internet Draft, Internet Engineering Task Force, March 1999. [5] L. Slutsman, "On Call Queuing in PINT" PINT WG presentation, December 7-11, 1998 [6] L. Slutsman, "Conference Call Services for PINT" Internet Draft, Internet Engineering Task Force, April, 1999 [7] A. Brusilovsky, V. Gurbani, A. Jain, D. Varney, "Need for PSTN Internet Notification (PIN) Services. A Proposal for a new Working Group" Internet Draft, Internet Engineering Task Force, February 1999. [8] A. Brusilovsky, E. Gausmann, V. Gurbani, A. Jain, "A Proposal for Internet Call Waiting Service using SIP. An Implementation Report." Internet Draft, Internet Engineering Task Force, January 1999. [9] C. Gao, A. Brusilovsky, J. Swinger, "Hybrid Network ACD" Intelligent Network Forum, IN/IP Working Group, London, May 1999 10] J.Rosenberg, H.Schulzrinne, "SIP For Presence", Internet Draft, Internet Engineering Task Force, March, 1999 [11] S.Bradner, "The Internet Standards Process", RFC2026 [12] J. Postel, "Instruction to RFC Authors", RFC 2223 [13] S. Petrack, "IP Access to PSTN Services: Basic Service Requirements, Definitions, and Architecture", Internet Draft, Internet Engineering Task Force June 1999 PSTN Internet Notification (PIN) Framework [Page 14] 9. Authors' Addresses Alec Brusilovsky E-mail: abrusilovsky@lucent.com Telephone: +1-630-713-8401 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Jim Buller E-mail: jim.buller@roke.co.uk Telephone: +44 (0)1794833666 Fax: +44 (0)1794833434 Siemens Roke Manor Research Ltd., Roke Manor, Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN Lawrence Conroy E-mail: lwc@roke.co.uk Telephone: +44 (1794) 833666 Fax: +44 (1794) 833434 Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN Vijay Gurbani E-mail: vkg@lucent.com Telephone: +1-630-224-0216 Fax: +1-630-713-5840 Lucent Technologies 263 Shuman Blvd. Naperville, IL 60566 USA Lev Slutsman E-mail: Lslutsman@att.com Telephone: 732-420-3756 Fax: AT&T Labs Room D5-3D26 June 1999 PSTN Internet Notification (PIN) Framework [Page 15] 200 Laurel Avenue S, Middletown, NJ, USA 07748 Glossary ACD Automatic Call Distribution ACID Advanced Caller Identification Delivery CCIB Call Completion Internet Busy DN Destination Number DP Detection Point ICR Internet Call Routing ICW Internet Call Waiting IN Intelligent Network LDCP Long Distance Carrier Provider MGCP Media Gateway Control Protocol NPL Notification Processing Language PIC Point-In-Call PTN Principal Telephone Number PSTN Public Switched Telephone Network SCP Service Control Point SN Service Node SP Service Provider VoIP Voice over IP (Internet Protocol) 10. Acknowledgments The authors would like to acknowledge Igor Faynberg, Hui-Lan Lu and Jonathan Rosenberg for their contributions to the creation of this document. Our special thanks to Steve Bellovin (AT&T), Corrado Moiso (CSELT), Lyndon Ong (Nortel) and Henry Sinnreich (MCI) for their insightful comments and help with this Internet Draft. June 1999 PSTN Internet Notification (PIN) Framework [Page 16] Figures: /\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\/\/\ ___________ \ __/___ ___\_______ \ | PINT | PINT \ PINT | PINT | | Exec | Telephone / | client |<---------->| server |gatewy|===| System | Network \ |_________| protocol / cloud |______| |_________| Cloud / \ \ / \ /\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/\/\/ /\/\/\/\/\/\/\ /\/\/\/\/\/\/\/\/\/\ ___________ \ __/___ ____\_______ \ | PIN | PIN \ PIN |Exec | |Requesting| Telephone / | server |<---------->| gateway |System|=A=| System | Network \ |_________| protocol / cloud |______| |__________| Cloud / \ \ / \ /\/\/\/\/\/\/\ \/\/\/\/\/\/\/\/\/\/\ /-----------------------------------< < Direction of the PIN Service Flow < \-----------------------------------< Figure 1 June 1999 --------------338156E83A69066CED83FF4D Content-Type: text/x-vcard; charset=us-ascii; name="abrusilovsky.vcf" Content-Description: Card for Alec Brusilovsky Content-Disposition: attachment; filename="abrusilovsky.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Brusilovsky;Alec x-mozilla-html:FALSE org:Lucent (jg7290000) version:2.1 email;internet:abrusilovsky@lucent.com title:MTS tel;fax:+1 630 713 5840 tel;work:+1 630 713 8401 adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S x-mozilla-cpt:;0 fn:Alec Brusilovsky end:vcard --------------338156E83A69066CED83FF4D-- --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Wed Jun 30 04:21:05 1999 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12362 for ; Wed, 30 Jun 1999 04:21:05 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id AA4E152DD; Wed, 30 Jun 1999 04:16:00 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1848D52E2; Wed, 30 Jun 1999 04:16:00 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com Message-Id: <199906281121.GAA05770@b04a24.exu.ericsson.se> Subject: Re: PSTN Interworking Draft To: lwc@roke.co.uk (Lawrence Conroy) Date: Mon, 28 Jun 1999 06:21:03 -0500 (CDT) Cc: Adam.Roach@ericsson.com, confctrl@ISI.EDU, pint@lists.research.bell-labs.com In-Reply-To: from "Lawrence Conroy" at Jun 26, 99 01:58:41 am From: "Adam B. Roach" X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >I have a slight qualm with this document. The PINT Drafts have had two >methods called SUBSCRIBE and NOTIFY for a long while now (basically since >Henning and Jonathon originally suggested them to us when what is now IMPP >started). > >I HOPE that the SUBSCRIBE/NOTIFY stuff of section 2.4 (with the note "This >document is not yet written.") isn't going to clash with the existing PINT >use, otherwise we'll break things (I trust that isn't the intent :). A >similar approach seems likely in any PIN work, and any revivification of >the SIP-for-Presence work. Any new document is not going to hit an empty >table. It is not mere coincidence that the method names I use in my document happen to be the same as those in two other drafts. I am aware of the existence of both documents. I am also aware of work currently underway to define semantics for subscribe and notify which allow nodes to subscribe to certain call-related events, including DTMF. It is this work I intend to reference in future drafts of my document. Since no drafts have yet been published on this work, I refer to it as unwritten. It would perhaps be more accurate to describe it as "unpublished." To avoid further confusion, reference to the other two other drafts should be made, with a note that neither are sufficient for the purposes of DTMF information transmission. The 01 version of my draft will reflect these changes. Thanks for your feedback. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA --------- This message came from the IETF PINT Working Group Mailing List. From owner-pint-outgoing@lists.research.bell-labs.com Wed Jun 30 11:33:14 1999 Received: from lists.research.bell-labs.com (H-135-180-161-172.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18954 for ; Wed, 30 Jun 1999 11:33:13 -0400 (EDT) Received: by lists.research.bell-labs.com (Postfix) id B21F752E3; Wed, 30 Jun 1999 11:30:02 -0400 (EDT) Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5DF3152E6; Wed, 30 Jun 1999 11:30:00 -0400 (EDT) Delivered-To: pint-local@paperless.dnrc.bell-labs.com From: faynberg@lucent.com (Igor Faynberg) To: "Adam B. Roach" , lwc@roke.co.uk (Lawrence Conroy) Date: Wed, 30 Jun 1999 11:29:25 -0400 Message-Id: <199906301529.LAA23336@holta.ho.lucent.com> Original-From: igorf@holta.ho.lucent.com (Igor Faynberg) Original-To: "Adam B. Roach" , lwc@roke.co.uk (Lawrence Conroy) Cc: confctrl@ISI.EDU, pint@lists.research.bell-labs.com Subject: Re: PSTN Interworking Draft Content-Type: text Sender: owner-pint@lists.research.bell-labs.com Precedence: bulk Adam Roach wrote: > To avoid further confusion, reference to the other two other drafts should be made, with a note that neither are sufficient for the purposes of DTMF information transmission. The 01 version of my draft will reflect these changes. > Adam, Thank you for your understanding and for quick reaction to Lawrence's note. I think you correctly point out that the key-words are overloaded; I think a solution to that is simply to use keywords that are different than the ones that have been spoken for already. The matter of fact is that SUBSCRIBE/NOTIFY statements that have already been agreed on as SIP extensions for PINT do have specific semantics, including the sequnces in which they appear. If you believe that the same mechanisms can be used elsewhere to do something else (i.e., DTMF transmission), you should ensure that whatever solution you propose is backward compatible. If you believe that the mechanisms may not be used (which is what I believe you are saying), the best thing would be to use different names. For example, in the case of DTMF, it would perhaps be appropriate to use DTMF-SUBSCRIBE, DTMF-NOTIFY. I reailize that my proposal may be controversial. Ever since Unix shell was introduced, some people thought it was great to have ONE shell script with hundreds of parameters covering ALL possible cases. Others argued that remembering such parameters and--especially--remembering the combinations of them that correspond to one or another specific usage is impossible and to learn the usages is very hard. It would much better to have several different shell procedures, each having its own set of necessary and sufficient parameters. This makes both the design and use unambigous. If you change something, you know that the impact of your change is localized. So, Lawrence and I do belong to this "don't overload" club, and we heartly welcome you to join it! Respectfully, Igor Faynberg --------- This message came from the IETF PINT Working Group Mailing List.