From mailman-owner@lists.bell-labs.com Sat Jul 1 05:03:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17858 for ; Sat, 1 Jul 2000 05:03:50 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C4F34444A for ; Sat, 1 Jul 2000 05:03:30 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: pint-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000701090330.1C4F34444A@lists.bell-labs.com> Date: Sat, 1 Jul 2000 05:03:30 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com 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, pint-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for pint-archive@lists.ietf.org: List Password // URL ---- -------- pint@lists.bell-labs.com hQOO http://lists.bell-labs.com/mailman/options/pint/pint-archive@lists.ietf.org From pint-admin@lists.bell-labs.com Wed Jul 12 16:20:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12447 for ; Wed, 12 Jul 2000 16:20:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94D9644438; Wed, 12 Jul 2000 16:20:01 -0400 (EDT) Delivered-To: pint@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id DEDAD44414 for ; Wed, 12 Jul 2000 16:16:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Jul 12 16:14:57 EDT 2000 Received: by lists.bell-labs.com (Postfix) id DFF0544358; Wed, 12 Jul 2000 16:01:47 -0400 (EDT) Delivered-To: pint@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 8C78A44347; Wed, 12 Jul 2000 16:01:47 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA11743; Wed, 12 Jul 2000 15:01:43 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA11739; Wed, 12 Jul 2000 15:01:42 -0500 Message-ID: <396CCF38.2F818672@lucent.com> Date: Wed, 12 Jul 2000 15:04:08 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: spirits@lists.bell-labs.com, pint list References: <006d01bfeb3f$8043d7a0$026fa8c0@nio3.loniis.ru> <396B38FA.E0831A30@lucent.com> Content-Type: multipart/mixed; boundary="------------6CE4AFDA6D1D383A8C124B9B" Subject: [PINT] Re: [SPIRITS] Request for SPIRITS introduction Sender: pint-admin@lists.bell-labs.com Errors-To: pint-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF PINT Mailing List X-BeenThere: pint@lists.bell-labs.com This is a multi-part message in MIME format. --------------6CE4AFDA6D1D383A8C124B9B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Another good resource of information/ideas on PSTN/IN Interworking might be the book: Converged Networks and Services: Internetworking IP and the PSTN by IgorFaynberg, Hui-Lan Lu and Larry Gabuzda: http://www.amazon.com/exec/obidos/ASIN/0471356441/qid%3D963414149/sr%3D1-2/102-3093969-4344961 Regards, Alec Alec Brusilovsky wrote: > The best place to start would be the PINT pages at: > http://www.ietf.org/html.charters/pint-charter.html > and > http://www.bell-labs.com/mailing-lists/pint/ > > As well as SPIRITS page at: > http://www.ietf.org/html.charters/spirits-charter.html > > You will be able to get to the mailing lists and archives of PINT and > SPIRITS from there. > > Glad to help, > Alec > > P.S. Other IETF WGs like SIGTRAN, MEGACO, SIP, IPTEL, ENUM might be of > interest too. Look for them at: > http://www.ietf.org/html.charters/wg-dir.html > > Marat Nourmiev wrote: > > > Hi all, > > > > You have very interesting subject for me. I am beginner in PSTN/IN - IP > > interworking and I am missing some of basic knowledge of it. Could you > > provide me a reference for introduction? > > > > Regards and thanks, > > Marat Nourmiev > > > > _______________________________________________ > > SPIRITS mailing list > > SPIRITS@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/spirits --------------6CE4AFDA6D1D383A8C124B9B 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 tel;fax:+1 630 713 5840 tel;work:+1 630 713 8401 x-mozilla-html:FALSE org:Lucent (jg7290000) version:2.1 email;internet:abrusilovsky@lucent.com title:MTS adr;quoted-printable:;;IHP 1A-423=0D=0A263 Shuman Blvd,P O Box 3050;Naperville;IL;60566-7050;U S x-mozilla-cpt:;-29888 fn:Alec Brusilovsky end:vcard --------------6CE4AFDA6D1D383A8C124B9B-- _______________________________________________ PINT mailing list PINT@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/pint From pint-admin@lists.bell-labs.com Tue Jul 18 05:03:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13374 for ; Tue, 18 Jul 2000 05:03:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4CC1044351; Tue, 18 Jul 2000 05:03:29 -0400 (EDT) Delivered-To: pint@lists.bell-labs.com Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16]) by lists.bell-labs.com (Postfix) with ESMTP id 851D044336; Tue, 18 Jul 2000 05:03:25 -0400 (EDT) Received: from oleane (dyn-1-1-161.Vin.dialup.oleane.fr [195.25.4.161]) by smtp1.cluster.oleane.net with SMTP id LAA02776; Tue, 18 Jul 2000 11:02:23 +0200 (CEST) Message-ID: <013401bff097$20cd0be0$0401a8c0@oleane.com> From: "mg263-8" To: Date: Tue, 18 Jul 2000 11:04:02 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0131_01BFF0A7.E194E720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [PINT] Implementing H.323 Sender: pint-admin@lists.bell-labs.com Errors-To: pint-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF PINT Mailing List X-BeenThere: pint@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0131_01BFF0A7.E194E720 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Implementing H.323": the VoIP deployment scenario International conference, Paris, 10-13 October http://www.upperside.fr/bah323.htm =20 ------=_NextPart_000_0131_01BFF0A7.E194E720 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
"Implementing H.323": the VoIP = deployment scenario
International conference, Paris, 10-13 = October
http://www.upperside.fr/bah32= 3.htm
 
 
------=_NextPart_000_0131_01BFF0A7.E194E720-- _______________________________________________ PINT mailing list PINT@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/pint From pint-admin@lists.bell-labs.com Fri Jul 21 16:56:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25764 for ; Fri, 21 Jul 2000 16:56:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8C4744337; Fri, 21 Jul 2000 16:56:05 -0400 (EDT) Delivered-To: pint@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 5D3A044336 for ; Wed, 19 Jul 2000 10:02:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 19 10:00:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 890354435F; Wed, 19 Jul 2000 09:47:11 -0400 (EDT) Delivered-To: pint@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id 4323444347; Wed, 19 Jul 2000 09:47:11 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA07778; Wed, 19 Jul 2000 09:47:10 -0400 Message-ID: <3975B15A.A9EACF28@lucent.com> Date: Wed, 19 Jul 2000 09:47:06 -0400 From: Hui-Lan Lu Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; U) X-Accept-Language: zh-TW,zh-CN MIME-Version: 1.0 To: ietf@ietf.org, sip@lists.bell-labs.com, pint@lists.bell-labs.com, spirits@lists.bell-labs.com, iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [PINT] The New Mailing list for SIP/IN Interworking Sender: pint-admin@lists.bell-labs.com Errors-To: pint-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF PINT Mailing List X-BeenThere: pint@lists.bell-labs.com Content-Transfer-Encoding: 7bit A mailing list for the upcoming BOF on SIP/IN interworking (SIN) has been set up to begin the relevant discussion. To join the list (ietf-sin@lists.bell-labs.com), please follow the instructions at http://lists.bell-labs.com/mailman/listinfo/ietf-sin. Hui-Lan Lu Lucent Technologies _______________________________________________ PINT mailing list PINT@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/pint From pint-admin@lists.bell-labs.com Tue Jul 25 02:44:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29547 for ; Tue, 25 Jul 2000 02:44:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 271E844375; Tue, 25 Jul 2000 02:44:17 -0400 (EDT) Delivered-To: pint@lists.bell-labs.com Received: from itc-eml2.ta.israel.madge.com (at.lannet.com [194.90.94.231]) by lists.bell-labs.com (Postfix) with ESMTP id 388064435F for ; Tue, 25 Jul 2000 02:43:49 -0400 (EDT) Received: by ITC-EML2 with Internet Mail Service (5.5.2650.21) id <3SMS68AC>; Tue, 25 Jul 2000 09:41:40 +0200 Message-ID: <15F58915DF84D311AC7D0090279AA614233A19@ITC-EML2> From: Dan Romascanu To: "'pint@lists.bell-labs.com'" Date: Tue, 25 Jul 2000 09:41:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFF60B.C5049BF0" Subject: [PINT] New PINT MIB Internet Draft Sender: pint-admin@lists.bell-labs.com Errors-To: pint-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF PINT Mailing List X-BeenThere: pint@lists.bell-labs.com 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_000_01BFF60B.C5049BF0 Content-Type: text/plain Please find attached a new version of the PINT MIB Internet Draft. This version contains some format changes and corrections required by the Operations and Management Area Director - Bert Wijnen, but no changes in semantics or content. At this stage we cannot submit officially the I-D because of the IETF meeting black-out. This is a good occasion to read and comment. Regards, Dan <> ------_=_NextPart_000_01BFF60B.C5049BF0 Content-Type: text/plain; name="draft-ietf-pint-mib-03.txt" Content-Disposition: attachment; filename="draft-ietf-pint-mib-03.txt" Content-Transfer-Encoding: quoted-printable PINT Working Group Murali Krishnaswamy Internet Draft Lucent Technologies Dan Romascanu Avaya Communication Expires January 2001 24 July 2000 Management Information Base for the PINT Services Architecture Abstract This memo describes a proposed MIB for the PINT Services Architecture. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Introduction PINT services are an emerging set of new Internet based applications where voice (and fax) requests to the PSTN (Public Switched = Telephone Krishnaswamy, Romascanu [Page = 1] Internet Draft PINT MIB July = 2000 Network) are carried over the Internet. RFC 2458 [1] gives a good introduction to the (pre-standard) PINT architecture and services. It also has examples of some of the early implementations of pre- PINT. This document defines a MIB which contains the elements for monitoring the performance of a PINT based service. The MIB consists of details of the four basic PINT services and their performance statistics measured under various criteria. It is not the purpose of this MIB to enable management of the PINT networking elements. We are concerned only with the PINT specific performance parameters. While it is understood that PINT service performance is closely related to host and network performance, they are not addressed here. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [2]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [3], RFC 1212 [4] and RFC 1215 [5]. The second = version, called SMIv2, is described in RFC 2578 [6], RFC 2579 [7] and = RFC 2580 [8]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [9]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 1906 = [11]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [9]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [14]. o A set of fundamental applications described in RFC 2573 [15] = and the view-based access control mechanism described in RFC 2575 Krishnaswamy, Romascanu [Page = 2] Internet Draft PINT MIB July = 2000 [16]. A more detailed introduction to the current SNMP Management = Framework can be found in RFC 2570 [17]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of = the MIB. 3. The need for PINT services monitoring MIB Traditionally voice (and fax) requests originate and terminate = inside a PSTN network. This network is well known for robust handling of = the requests, in terms of availability and security. However when the requests originate from the Internet there is a concern both on the part of the user as well as the provider about issues like reliable forwarding of the call requests to the PINT gateway under various network conditions, user/host authentication, secure handling of the user information etc. Performance and security management becomes all the more important where PINT services cross multiple = administra- tive domains (or providers). This MIB is an attempt to list the parameters that need to be moni- tored on an user, PINT client, PINT server and PINT gateway basis. (PINT services, their invocation methods/protocols and security issues associated with the PINT architecture are discussed in detail in [18]). 4. PINT MIB - Overview Following is a list of some explanations on the MIB definitions that Krishnaswamy, Romascanu [Page = 3] Internet Draft PINT MIB July = 2000 we have chosen to construct. o The basic purpose of this MIB is to monitor the access to PINT services both from the performance and security point of view. Information may pertain to a certain user or his/her system (PINT client) or the system providing the PINT services (PINT server) or the PINT gateway that forwards the call to the PSTN network. o We propose to build the configuration table as an extension of the Application MIB - RFC 2287 [19] using the augments con- struct. Server location and contact might be retrieved from = the standard MIB-II sysLocation and sysContact objects. There is no need to replicate this information in the PINT MIB. However, = the PINT administrator may be a different person than the sysadmin with global responsibilities, thus a pintSysContact object is defined. o We chose to monitor the gateway connections from the PINT server. While the agent runs in the PINT servers, the connec- tions to the gateways might need to be monitored in order to understand what goes on. We placed them in a separate MIB = group, and by using MODULE-COMPLIANCE clauses, agents that cannot implement this stuff will not be mandated to do it. o There is no traps definition in this preliminary proposal. Note that thresholding on counters is always possible by using a standard mechanism defined by the Remote Monitoring MIB, that can be referenced here. Some events that may be defined by = using this mechanisms: * continuous login/authentication failure or refusal from a particular client or user * nuisance call - repeated calls (within a specified period) to a number originating from the same user o The client performance and user performance tables may be = rather resource demanding for an agent implementation. In some MIBs, like the Remote Monitoring (RMON) MIBs, control mechanisms were built in order to activate those statistics on demand. If needed, a sorting ('topN') mechanism can be designed, so that a sorted view of clients or users is presented for the high level Krishnaswamy, Romascanu [Page = 4] Internet Draft PINT MIB July = 2000 debugging. o We built a time-distribution trying to cover both short-lived, as well as longer sessions (1-10 secs, 10 secs - 1 min., 1-15 min., 15 mins-24 hours, longer). o PintServerClientAddress is defined as a SnmpAdminString. It may include an IpAddress and/or name, but we preferred to minimize the number of indices at this stage, and keep a human-readable format at the same time. o We define pintServerUserIdName as the UserId. This UserId = needs to be unique across multiple PINT servers and gateways (depend- ing on the architecture) and is mapped to the SessionId. One way to achieve this uniqueness is by appending clientId to the UserId string before sending to the PINT server. The SessionId could then be a combination of this new UserId and a timestamp. 5. Definitions PINT-MIB DEFINITIONS ::=3D BEGIN IMPORTS OBJECT-TYPE, Counter32, MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SysApplInstallPkgIndex FROM SYSAPPL-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- RFC 2271 [20] pintMib MODULE-IDENTITY LAST-UPDATED "200007241525Z" ORGANIZATION "IETF PINT Working Group" CONTACT-INFO " Chairs: Krishnaswamy, Romascanu [Page = 5] Internet Draft PINT MIB July = 2000 Steve Bellovin E-mail: smb@research.att.com Igor Faynberg E-mail: faynberg@lucent.com Murali Krishnaswamy Postal: 3C-512, 101 Crawfords Corner Rd. Holmdel, NJ 07733 Tel: +1 (732)949-3611 FAX: +1 (732)949-3210 E-mail: murali@lucent.com Dan Romascanu Postal: Atidim Technology Park, Bldg 3 Tel Aviv, Israel Tel: +972 3 6458414 E-mail: dromasca@avaya.com General Discussion:pint@lists.bell-labs.com To Subscribe: pint-request@lists.bell-labs.com In Body: subscribe your-email-addres Archive: http://www.bell-labs.com/mailing-lists/pint/ " DESCRIPTION "This MIB defines the objects necessary to monitor PINT Services" REVISION "200007241525Z" DESCRIPTION "Initial version, published as RFC xxxx." ::=3D { mib-2 99999 } -- Not an IANA number PintServiceType ::=3D TEXTUAL-CONVENTION STATUS current SYNTAX INTEGER { r2C(1), -- Request-to-Talk r2F(2), -- Request-to-Fax r2FB(3), -- Request-to-Fax-Back r2HC(4) -- Request-to-Hear-Content } DESCRIPTION Krishnaswamy, Romascanu [Page = 6] Internet Draft PINT MIB July = 2000 "This TC describes the type of a PINT service." PintPerfStatPeriod ::=3D TEXTUAL-CONVENTION STATUS current SYNTAX INTEGER { last30sec(1), -- Performance Statics for the last 30 = sec last15min(2), -- 15 min last24Hr(3), -- 24 Hour sinceReboot(4) -- Since the time the pint server = was -- last rebooted } DESCRIPTION "This TC describes the statistics period of time. Note that the values of the counters indexed with a value SinceReboot(4) can be potentially affected by a counter rollover. It is the responsibility of the application using this object to take into account that the counter has been zeroed each time it reached a value of (2**32-1)." pintServerConfig OBJECT IDENTIFIER ::=3D { pintMib 1 } pintServerMonitor OBJECT IDENTIFIER ::=3D { pintMib 2 } pintMibConformance OBJECT IDENTIFIER ::=3D { pintMib 3 } -- pintServerConfig - PINT configuration MIB variables pintReleaseNumber OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of version of the PINT protocol supported by this agent." ::=3D { pintServerConfig 1 } pintSysContact OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-write STATUS current DESCRIPTION "Contact information related to the administration of the PINT services." ::=3D { pintServerConfig 2 } pintApplInstallPkgTable OBJECT-TYPE Krishnaswamy, Romascanu [Page = 7] Internet Draft PINT MIB July = 2000 SYNTAX SEQUENCE OF PintApplInstallPkgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table describing the PINT applications that are installed." ::=3D { pintServerConfig 3 } pintApplInstallPkgEntry OBJECT-TYPE SYNTAX PintApplInstallPkgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries per PINT Application." AUGMENTS { sysApplInstallPkgIndex } ::=3D { pintApplInstallPkgTable 1 } PintApplInstallPkgEntry ::=3D SEQUENCE { pintApplInstallPkgDescription SnmpAdminString } pintApplInstallPkgDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Textual description of the installed PINT application." ::=3D { pintApplInstallPkgEntry 1 } pintRegisteredGatewayTable OBJECT-TYPE SYNTAX SEQUENCE OF PintRegisteredGatewayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table describing the registered gateway applications." ::=3D { pintServerConfig 4 } pintRegisteredGatewayEntry OBJECT-TYPE SYNTAX PintRegisteredGatewayEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries per Registered Gateway Application." AUGMENTS { sysApplInstallPkgIndex, pintRegisteredGatewayName } ::=3D { pintRegisteredGatewayTable 1 } pintRegisteredGatewayEntry ::=3D SEQUENCE { pintRegisteredGatewayName SnmpAdminString Krishnaswamy, Romascanu [Page = 8] Internet Draft PINT MIB July = 2000 pintRegisteredGatewayDescription SnmpAdminString } pintRegisteredGatewayName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "Name of the registered gateway." ::=3D { pintRegisteredGatewayEntry 1 } pintRegisteredGatewayDescription OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "Textual description of the registered gateway." ::=3D { pintRegisteredGatewayEntry 2 } -- pintServerMonitor - PINT monitoring statistics MIB variables pintServerGlobalPerf OBJECT IDENTIFIER ::=3D {pintServerMonitor 1 } pintServerClientPerf OBJECT IDENTIFIER ::=3D {pintServerMonitor 2 } pintServerUserIdPerf OBJECT IDENTIFIER ::=3D {pintServerMonitor 3 } pintServerGatewayPerf OBJECT IDENTIFIER ::=3D {pintServerMonitor 4 } pintServerGlobalStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PintServerGlobalStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table displaying the monitored global server statistics." ::=3D { pintServerGlobalPerf 1 } pintServerGlobalStatsEntry OBJECT-TYPE SYNTAX PintServerGlobalStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in the global statistics table. One entry is defined for each monitored service type and performance statistics collection period." INDEX {pintServerServiceTypeIndex, = pintServerPerfStatPeriodIndex} ::=3D { pintServerGlobalStatsTable 1 } PintServerGlobalStatsEntry ::=3D SEQUENCE { Krishnaswamy, Romascanu [Page = 9] Internet Draft PINT MIB July = 2000 pintServerServiceTypeIndex = PintServiceType, pintServerPerfStatPeriodIndex = PintPerfStatPeriod, pintServerGlobalCallsReceived Counter32, pintServerGlobalSuccessfulCalls Counter32, pintServerGlobalDisconnectedCalls Counter32, pintServerGlobalDisconnectedClientUserAuthorizationFailureCalls Counter32, pintServerGlobalDisconnectedServerProblemCalls Counter32, pintServerGlobalDisconnectedGatewayProblemCalls Counter32 } pintServerServiceTypeIndex OBJECT-TYPE SYNTAX PintServiceType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the monitored service." ::=3D { pintServerGlobalStatsEntry 1 } pintServerPerfStatPeriodIndex OBJECT-TYPE SYNTAX PintPerfStatPeriod MAX-ACCESS not-accessible STATUS current DESCRIPTION "Time period for which the performance statistics are requested from the pint server." ::=3D { pintServerGlobalStatsEntry 2 } pintServerGlobalCallsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of received global calls." ::=3D { pintServerGlobalStatsEntry 3 } pintServerGlobalSuccessfulCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global successful calls." ::=3D { pintServerGlobalStatsEntry 4 } pintServerGlobalDisconnectedCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Krishnaswamy, Romascanu [Page = 10] Internet Draft PINT MIB July = 2000 STATUS current DESCRIPTION "Number of global disconnected (failed) calls." ::=3D { pintServerGlobalStatsEntry 5 } pintServerGlobalDisconnectedClientUserAuthorizationFailureCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global calls that were disconnected because of client or user authorization failure." ::=3D { pintServerGlobalStatsEntry 6 } pintServerGlobalDisconnectedServerProblemCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global calls that were disconnected because of server problems." ::=3D { pintServerGlobalStatsEntry 7 } pintServerGlobalDisconnectedGatewayProblemCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of global calls that were disconnected because of gateway problems." ::=3D { pintServerGlobalStatsEntry 8 } pintServerClientStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PintServerClientStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table displaying the monitored server client statistics." ::=3D { pintServerClientPerf 1 } pintServerClientStatsEntry OBJECT-TYPE SYNTAX PintServerClientStatsEntry Krishnaswamy, Romascanu [Page = 11] Internet Draft PINT MIB July = 2000 MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in the client server statistics table. One entry is defined for each client identified by name, monitored service type and performance statistics collection period." INDEX {pintServerClientAddress, pintServerServiceTypeIndex, pintServerPerfStatPeriodIndex} ::=3D { pintServerClientStatsTable 1 } PintServerClientStatsEntry ::=3D SEQUENCE { pintServerClientAddress = SnmpAdminString, pintServerClientCallsReceived Counter32, pintServerClientSuccessfulCalls Counter32, pintServerClientDisconnectedCalls Counter32, pintServerClientDisconnectedClientAuthorizationFailureCalls Counter32, pintServerClientDisconnectedEgressFacilityProblemCalls Counter32 } pintServerClientAddress OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the monitored client identified by its address represented as as a string." ::=3D { pintServerClientStatsEntry 1 } pintServerClientCallsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received from the specific client." ::=3D { pintServerClientStatsEntry 2 } pintServerClientSuccessfulCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the client successfully completed." ::=3D { pintServerClientStatsEntry 3 } Krishnaswamy, Romascanu [Page = 12] Internet Draft PINT MIB July = 2000 pintServerClientDisconnectedCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received from the client, and that were disconnected (failed)." ::=3D { pintServerClientStatsEntry 4 } pintServerClientDisconnectedClientAuthorizationFailureCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the client that were disconnected because of client authorization failure." ::=3D { pintServerClientStatsEntry 5 } pintServerClientDisconnectedEgressFacilityProblemCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the client that were disconnected because of egress facility problems." ::=3D { pintServerClientStatsEntry 6 } pintServerUserIdStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PintServerUserIdStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table displaying the monitored Pint service user statistics." ::=3D { pintServerUserIdPerf 1 } pintServerUserIdStatsEntry OBJECT-TYPE SYNTAX PintServerUserIdStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in the user statistics table. One entry is defined for each user identified by name, each monitored service type and performance statistics collection period." Krishnaswamy, Romascanu [Page = 13] Internet Draft PINT MIB July = 2000 INDEX {pintServerUserIdName, pintServerServiceTypeIndex, pintServerPerfStatPeriodIndex} ::=3D { pintServerUserIdStatsTable 1 } PintServerUserIdStatsEntry ::=3D SEQUENCE { pintServerUserIdName UserIdName, pintServerUserIdCallsReceived Counter32, pintServerUserIdSuccessfulCalls Counter32, pintServerUserIdDisconnectedCalls Counter32, pintServerUserIdDisconnectedUserIdAuthorizationFailureCalls Counter32, pintServerUserIdDisconnectedEgressFacilityProblemCalls Counter32 } pintServerUserIdName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identifier of the monitored user identified by its name." ::=3D { pintServerUserIdStatsEntry 1 } pintServerUserIdCallsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received from the specific user." ::=3D { pintServerUserIdStatsEntry 2 } pintServerUserIdSuccessfulCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the user successfully completed." ::=3D { pintServerUserIdStatsEntry 3 } pintServerUserIdDisconnectedCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received from the user that were disconnected (failed)." ::=3D { pintServerUserIdStatsEntry 4 } Krishnaswamy, Romascanu [Page = 14] Internet Draft PINT MIB July = 2000 pintServerUserIdDisconnectedUserIdUserAuthorizationFailureCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the user that were disconnected because of user authorization failure." ::=3D { pintServerUserIdStatsEntry 5 } pintServerUserIdDisconnectedEgressFacilityProblemCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls from the user that were disconnected because of egress facility problems." ::=3D { pintServerUserIdStatsEntry 6 } pintServerGatewayStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF PintServerGatewayStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table displaying the monitored gateway statistics." ::=3D { pintServerGatewayPerf 1 } pintServerGatewayStatsEntry OBJECT-TYPE SYNTAX PintServerGatewayStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Entries in the gateway table. One entry is defined for each gateway identified by name, each monitored service type and performance statistics collection period." INDEX { pintRegisteredGatewayName, pintServerServiceTypeIndex, pintServerPerfStatPeriodIndex ::=3D { pintServerGatewayStatsTable 1 } PintServerGatewayStatsEntry ::=3D SEQUENCE { pintServerGatewayCallsReceived Counter32, pintServerGatewaySuccessfulCalls Counter32, pintServerGatewayDisconnectedCalls Counter32 } Krishnaswamy, Romascanu [Page = 15] Internet Draft PINT MIB July = 2000 pintServerGatewayCallsReceived OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls received at the specified gateway." ::=3D { pintServerGatewayStatsEntry 1 } pintServerGatewaySuccessfulCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls successfully completed at the specified gateway." ::=3D { pintServerGatewayStatsEntry 2 } pintServerGatewayDisconnectedCalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of calls that were disconnected (failed) at the specified gateway." ::=3D { pintServerGatewayStatsEntry 3 } -- -- Notifications Section -- (none defined) -- -- -- Conformance Section -- pintMibCompliances OBJECT IDENTIFIER ::=3D { pintMibConformance 1 } pintMibGroups OBJECT IDENTIFIER ::=3D { pintMibConformance 2 } pintMibCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Describes the requirements for conformance to the PINT MIB." MODULE -- this module MANDATORY-GROUPS { pintMibConfigGroup, pintMibMonitorGroup } ::=3D { pintMibCompliances 1 } Krishnaswamy, Romascanu [Page = 16] Internet Draft PINT MIB July = 2000 pintMibConfigGroup OBJECT-GROUP OBJECTS { pintReleaseNumber, pintSysContact, pintApplInstallPkgDescription, pintRegisteredGatewayName, pintRegisteredGatewayDescription } STATUS current DESCRIPTION "A collection of objects providing configuration information for a PINT Server." ::=3D { pintMibGroups 1 } pintMibMonitorGroup OBJECT-GROUP OBJECTS { pintServerServiceTypeIndex, pintServerPerfStatPeriodIndex, pintServerGlobalCallsReceived, pintServerGlobalSuccessfulCalls, pintServerGlobalDisconnectedCalls, pintServerGlobalDisconnectedClientUserAuthorizationFailureCalls, pintServerGlobalDisconnectedServerProblemCalls, pintServerGlobalDisconnectedGatewayProblemCalls, pintServerClientAddress, pintServerClientCallsReceived, pintServerClientSuccessfulCalls, pintServerClientDisconnectedCalls, pintServerClientDisconnectedClientAuthorizationFailureCalls, pintServerClientDisconnectedEgressFacilityProblemCalls, pintServerUserIdName, pintServerUserIdCallsReceived, pintServerUserIdSuccessfulCalls, pintServerUserIdDisconnectedCalls, pintServerUserIdDisconnectedUserIdAuthorizationFailureCalls, pintServerUserIdDisconnectedEgressFacilityProblemCalls, pintServerGatewayCallsReceived, pintServerGatewaySuccessfulCalls, pintServerGatewayDisconnectedCalls } STATUS current DESCRIPTION "A collection of objects providing monitoring information for a PINT Server." ::=3D { pintMibGroups 2 } Krishnaswamy, Romascanu [Page = 17] Internet Draft PINT MIB July = 2000 END 6. Acknowledgements The authors would like to thank Igor Faynberg for his encouragement to produce this work. 7. Security Considerations There is only one management object defined in this MIB that has a MAX-ACCESS clause of read-write (pintSysContact). There are no = read- create objects. This read-write object may be considered sensitive = or vulnerable in some network environments. The support for SET opera- tions in a non-secure environment without proper protection can have a negative effect on network operations. There are a number of managed objects in this MIB that may contain information that may be sensitive from a business perspective. One could be the customer identification (UserIdName). Also information on PINT services performance might itself be need to be guarded. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending = them over the network via SNMP. Not all versions of SNMP provide = features for such a secure environment. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is = no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security fea- tures as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [13] and the View- based Access Control Model RFC 2575 [16] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly config- ured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/cre- ate/delete) them. 8. IANA Considerations All extensions to the values listed in this MIB must be done through Krishnaswamy, Romascanu [Page = 18] Internet Draft PINT MIB July = 2000 Standards Action processes as defined in RFC 2434 [21]. 9. References [1] H.Lu, et. al, "Toward the PSTN/Internet Inter-Networking --Pre- PINT Implementations", RFC 2458, November 1998. [2] Wijnen, B., Harrington, D., and Presuhn, R., "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [3] Rose, M. and McCloghrie, K., "Structure and Identification of = Man- agement Information for TCP/IP-based Internets", RFC 1155, May 1990. [4] Rose, M. and McCloghrie, K., "Concise MIB Definitions", RFC 1212, March 1991. [5] Rose, M., "A Convention for Defining Traps for use with the = SNMP", RFC 1215, March 1991. [6] McCloghrie, K., Perkins, D., and Schoenwaelder, J., "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. [7] McCloghrie, K., Perkins, D., and Schoenwaelder, J., "Textual Con- ventions for SMIv2", RFC 2579, April 1999. [8] McCloghrie, K., Perkins, D., and Schoenwaelder, J., "Conformance Statements for SMIv2", RFC 2580, April 1999. [9] Case, J., Fedor, M., Schoffstall, M., and Davin, J., "Simple Net- work Management Protocol", RFC 1157, May 1990. [10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., = "Introduc- tion to Community-based SNMPv2", RFC 1901, January 1996. [11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., = "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [12] Case, J., Harrington D., Presuhn R., and Wijnen, B., "Message = Pro- cessing and Dispatching for the Simple Network Management = Protocol (SNMP)", RFC 2572, April 1999. [13] Blumenthal, U. and Wijnen, B., "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol = (SNMPv3)", RFC 2574, April 1999. Krishnaswamy, Romascanu [Page = 19] Internet Draft PINT MIB July = 2000 [14] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for Version 2 of the Simple Network Management = Protocol (SNMPv2)", RFC 1905, January 1996. [15] Levi, D., Meyer, P., and Stewart, B., "SNMPv3 Applications", RFC 2573, April 1999. [16] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [17] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction = to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [18] S. Petrack, L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", = draft-ietf- pint-protocol-01.txt, 14 July 1999. [19] C. Krupczak, J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [20] D. Harrington, R. Presuhn, B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [21] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Consid- erations Section in RFCs", RFC 2434, October 1998. 10. Authors' Addresses Murali Krishnaswamy Lucent Technologies 3C-512, 101 Crawfords Corner Rd. Holmdel, NJ 07733 Tel: +1 (732)949-3611 Fax: +1 (732)949-3210 E-mail: murali@lucent.com Dan Romascanu Avaya Communication Atidim Technology Park, Bldg 3 Tel Aviv, Israel Tel: +972 3 6458414 E-mail: dromasca@lucent.com Krishnaswamy, Romascanu [Page = 20] ------_=_NextPart_000_01BFF60B.C5049BF0-- _______________________________________________ PINT mailing list PINT@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/pint From pint-admin@lists.bell-labs.com Fri Jul 28 11:00:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08815 for ; Fri, 28 Jul 2000 11:00:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F34DF443CD; Fri, 28 Jul 2000 11:00:21 -0400 (EDT) Delivered-To: pint@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with ESMTP id 3312944336 for ; Fri, 28 Jul 2000 11:00:19 -0400 (EDT) Received: from [193.118.192.80] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 28 Jul 2000 15:57:49 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Fri, 28 Jul 2000 16:00:07 +0100 To: pint@lists.bell-labs.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" Subject: [PINT] Sorry for filling your other mailbox... Sender: pint-admin@lists.bell-labs.com Errors-To: pint-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF PINT Mailing List X-BeenThere: pint@lists.bell-labs.com Hi Folks, Due to the format of the draft(s) being mangled in transit to Internet-Drafts, the things I want to talk about on Monday won't appear in the I-D archive until after the meeting :(. Sorry for this, but here follows the PINT draft. Note that it's pretty much a mirror image of the SPIRITS one, but the implications are a little different, and some things have been specified already in PSP (RFC 2848): ------------------------------------------------------------ PINT Working Group L. Conroy INTERNET-DRAFT Siemens Roke Manor Research Category: Informational J. Buller Expires: January 2001 Unisphere Solutions A list of possible PINT functions Status of this Memo This is an Internet-Draft and is in full conformance with all the provisions of section 10 of RFC2026. This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (c) The Internet Society (2000). All rights reserved. Abstract This Internet Draft is one of a pair written at the request of one of the SPIRITS Working Group co-chairs in order to elicit discussion on what extended functionality SPIRITS may be used to provide; the PINT work has similar requirements for a definition of the building blocks that might be used in future services (and so need to be supported by the protocol). This note provides the "mirror image" of the associated SPIRITS draft, listing functional building blocks that may be executed in response to future PINT protocol requests. Conroy, Buller [Page 1] July, 2000 Contents of the rest of this document are as follows: Section 1...................................................... 2 Introduction Section 2...................................................... 2 PINT functions Section 3...................................................... 5 Security Section 4...................................................... 5 Summary Section 5...................................................... 6 References Section 6...................................................... 6 Authors' addresses 1. Introduction This document lists 'possible' extensions of functionality ("building blocks") to PINT to aid discussion. It should be read in conjunction with the equivalent SPIRITS document ("draft-conroy-spirits-act-00.txt"). It is expected that future extensions to PINT services will use more of the features available within the PSTN/IN, and so these functions might be expected to be exposed to requesting clients; this will almost certainly be reflected in future use of the PINT Service Protocol. 2. PINT functions 1) Registrations/ Deregistrations of an PSTN entity to the Internet entity (getting trusted entities 'known' to the Internet entity) This is done already in PINT Service Protocol, using REGISTER messages. 2) Registration of available services in the PSTN domain This is done already in the PINT Service Protocol (PSP). Note that in PSP, this is carried out at the same time as registering an entity; both are requested in a single REGISTER message. The entity registers not only the service (the user-part) but also the address to which such requests should be sent (the host-part). 3) Request service handling by entity in PSTN domain This is part of the normal PINT request processing, and as such is defined in PSP already. Conroy, Buller [Page 2] July, 2000 4) Service Handling terminated by entity in PSTN domain and handed back to entity in Internet domain for resumption. PSTN domain Service handler takes no further interest in service This appears to be the normal PINT service processing. However, it may be extended as a function that has the effect of "handing off" responsibility for processing a PSTN service to the Internet. Whilst it is not clear quite how such an arrangement could be arranged in practice, it is nevertheless a pattern that we may want to consider. 5) Service handling passed back to entity in Internet domain. However, an interest (perhaps implemented as some kind of monitoring function) is maintained by service handler in the PSTN domain relating to 'this' instance of service This potential function has the effect of "handing off" responsibility for processing a PSTN service call to the Internet, whilst allowing the PSTN service processing to "maintain an interest" in the disposition of the service processing (possibly by the Internet entity returning status information to the PSTN entity. Again, this relationship is not covered in the existing PINT architecture, but could be appropriate for some complex services. For example, a PINT executive system may have been asked to make a call leg from a gateway onwards to a PSTN end user (see next function, for example), with the Internet entity continuing execution of the overall service by joining a different call leg from an Internet user to that call leg within the gateway. 6) Entity in the Internet domain requests an initial PSTN call This building block can be seen as a re-statement of the existing PINT service requests. 7) Entity in the Internet requests a PSTN call leg This is a building block that is a primitive that might be viewed as part of the implementation of a PINT Click-to-Dial service. It differs in that, as only one call leg is requested, and the PINT model implies a third-party call control model is used in the execution of the service, there will have to be a subsequent "join leg" primitive action. 8) Entity in the Internet requests deletion of a PSTN call leg To ensure widest possible implementation, the existing PINT architecture does not assume that any existing Service call can be terminated on request from an Internet entity. However, it is at least possible that PINT Executive Systems that implement CS-2 call leg manipulation actions can process such requests. 9) Entity in the Internet requests a connection of 2 or more PSTN call legs This function differs from the existing PINT Click-to-Dial service in that there may be more than two call legs that are to be connected (or joined), the way in which the call legs are referred to may differ, and that this would normally consist of joining a set of call legs that have been created previously using a number of separate "add leg" primitives. Conroy, Buller [Page 3] July, 2000 10) Entity in the Internet domain requests transfer of a PSTN call leg At present, PINT does not define a service to transfer a call leg from one association to another. However, this is a useful service, and so should be considered. 11) Entity in Internet domain requests a Hold/Resume for PSTN-based call leg The existing PINT services do not define a mechanism to change a service call once in place. This function is another primitive that would let an Internet entity to manipulate an existing service call, and so extend more features of the I.N. service processing "upwards". 12) Event Notification requests sent from Internet to PSTN domain This function is defined already within the PINT Service Protocol (PSP), using the Subscribe method. However, its use might be extended to cover a request for status on a wider range of entities than a PINT service. 13) Event Notification responses sent from PSTN domain to Internet domain This function is defined already within PSP (using the Notify method). 14) Event Notification Session Termination This function is defined already within PSP (in the Unsubscribe method). 15) The ability to request an entity in the PSTN domain to Output tones or play announcements or messages As before, this primitive extends commands that exist in the PSTN "upwards" to the Internet. This function would allow a PSTN call leg associated with an Intelligent Peripheral to have tones or announcements (or voice prompts) played out to it. 16) The ability for an entity in the Internet domain to collect information from the PSTN domain (e.g. DTMF) This primitive reflects the "collect" command that exists within the Intelligent Network. In the PINT case, the collected digits would be returned to the Internet entity that made the service primitive request. 17) The ability to set service data and user data in the PSTN domain from the Internet domain This is a major function indeed. It might enable I.N. triggers to be set or PSTN customer service status (i.e. whether or not a PSTN user is subscribed to a service) to be changed, and might also allow current PSTN status to be returned. In its latter guise it is similar to the Subscribe/Notify mechanism that exists within PSP already, but in this case there is no prior PINT service on which status notifications are to be returned. The details of this primitive warrant further discussion. Conroy, Buller [Page 4] July, 2000 3. Security Security issues are for further discussion. This document is only intended to provide the basis for such discussion. 4. Summary This note has described some functional building blocks for PINT services. The functional building blocks were: * Registrations/ Deregistrations of an PSTN entity to the Internet entity (getting trusted entities 'known' to the Internet entity) * Registration of available services in the PSTN domain * Request service handling by entity in PSTN domain * Service Handling terminated by entity in PSTN domain and handed back to entity in Internet domain for resumption. PSTN domain Service handler takes no further interest in service * Service handling passed back to entity in Internet domain. However, an interest (perhaps implemented as some kind of monitoring function) is maintained by service handler in the PSTN domain relating to 'this' instance of service * Entity in the Internet domain requests an initial PSTN call * Entity in the Internet requests a PSTN call leg * Entity in the Internet requests deletion of a PSTN call leg * Entity in the Internet requests a connection of 2 or more PSTN call legs * Entity in the Internet domain requests transfer of a PSTN call leg * Entity in Internet domain requests a Hold/Resume for PSTN-based call leg * Event Notification requests sent from Internet domain to PSTN domain * Event Notification responses sent from PSTN domain to Internet domain * Event Notification session termination * The ability to request an entity in the PSTN domain to Output tones or play announcements or messages Conroy, Buller [Page 5] July, 2000 * The ability for an entity in the Internet domain to collect information from the PSTN domain (e.g. DTMF) * The ability to set service data and user data in the PSTN domain from the Internet domain 5. References [1] Postel, J., "Instruction to RFC Authors", RFC 1543, October 1993. [2] Petrack, S., Conroy, L., "The PINT Service Protocol: Extensions to SIP and SDP for IP access to Telephone Call Services", RFC 2848, June 2000. 6. Authors' Addresses Lawrence Conroy Siemens Roke Manor Research Roke Manor Old Salisbury Lane Romsey, Hampshire U.K. SO51 0ZN Phone: +44 (1794) 833666 EMail: lwc@roke.co.uk Jim Buller Unisphere Solutions, 900 Broken Sound Parkway, B12S Boca Raton, FL 33487. USA Phone: +1 561 923 3132 EMail: jBuller@unispheresolutions.com Conroy, Buller [Page 6] -- All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd pay me for them" | |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| _______________________________________________ PINT mailing list PINT@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/pint