From mailman-owner@lists.bell-labs.com Tue Aug 1 05:04:37 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 FAA03473 for ; Tue, 1 Aug 2000 05:04:37 -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 6BE8C445F3 for ; Tue, 1 Aug 2000 05:02:36 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: spirits-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000801090236.6BE8C445F3@lists.bell-labs.com> Date: Tue, 1 Aug 2000 05:02:36 -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, spirits-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 spirits-archive@lists.ietf.org: List Password // URL ---- -------- spirits@lists.bell-labs.com QMKP http://lists.bell-labs.com/mailman/options/spirits/spirits-archive@lists.ietf.org From spirits-admin@lists.bell-labs.com Mon Aug 14 16:20:22 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 QAA18275 for ; Mon, 14 Aug 2000 16:20:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2608244367; Mon, 14 Aug 2000 16:14:40 -0400 (EDT) Delivered-To: spirits@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 2879E44338 for ; Mon, 14 Aug 2000 16:08:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Aug 14 16:06:31 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6F2624436E; Mon, 14 Aug 2000 15:53:18 -0400 (EDT) Delivered-To: spirits@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 2342044347 for ; Mon, 14 Aug 2000 15:53:18 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21078; Mon, 14 Aug 2000 14:53:14 -0500 Cc: Steve Bellovin , "iesg-secretary@ietf.org" , SPIRITS list , Allison Mankin Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21062; Mon, 14 Aug 2000 14:53:12 -0500 Message-ID: <39984ED0.752271EC@lucent.com> Date: Mon, 14 Aug 2000 14:56:00 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: Scott Bradner Original-CC: Steve Bellovin , "iesg-secretary@ietf.org" , SPIRITS list , Allison Mankin Content-Type: multipart/mixed; boundary="------------99CF1932C56587EBAE03A5FB" Subject: [SPIRITS] Submission of the Pre-SPIRITS Implementation draft for Informational RFC Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com This is a multi-part message in MIME format. --------------99CF1932C56587EBAE03A5FB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Scott, According to Section 7.5 of RFC 2418, the SPIRITS chairmen are submitting the I-D 'draft-ietf-spirits-implementations-01', http://www.ietf.org/internet-drafts/draft-ietf-spirits-implementations-01.txt for the IESG consideration on the subject of approval its publication as an Informational RFC. This draft has been a working item and a milestone in the SPIRITS charter, it has undergone a six weeks long WG Last Call and has incorporated comments/changes from the SPIRITS WG constituency. Presently, this I-D reflects the consensus of the SPIRITS WG. The abstract of the draft is attached. Regards, Steve Bellovin Alec Brusilovsky ******************************************************* Abstract This document contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those involved in the interactions of the Internet and Public Switched Telephony Network (PSTN) and, in particular, the interactions initiated by the PSTN. Surveying the implementations, we can make the following observations: o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it. o SIP is used in most of the implementations as the base communi- cations protocol between the PSTN and Internet. (NEC's implemen- tation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.) o All implementations use IN-based solutions for the PSTN part. It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementa-tions inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of SPIRITS services. --------------99CF1932C56587EBAE03A5FB 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 --------------99CF1932C56587EBAE03A5FB-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Sun Aug 20 22:30:04 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 WAA13171 for ; Sun, 20 Aug 2000 22:30:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E76344337; Sun, 20 Aug 2000 22:30:04 -0400 (EDT) Delivered-To: spirits@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 2F79E44336 for ; Sun, 20 Aug 2000 22:30:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Sun Aug 20 22:29:59 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 01AE444370; Sun, 20 Aug 2000 22:16:50 -0400 (EDT) Delivered-To: spirits@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 A0E3D44347 for ; Sun, 20 Aug 2000 22:16:49 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id VAA18835; Sun, 20 Aug 2000 21:16:46 -0500 Cc: Steve Bellovin Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id VAA18830; Sun, 20 Aug 2000 21:16:43 -0500 Message-ID: <39A091B6.FB3990A9@lucent.com> Date: Sun, 20 Aug 2000 21:19:34 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: SPIRITS list Original-CC: Steve Bellovin Content-Type: multipart/mixed; boundary="------------A49BB5125A16346779A02E66" Subject: [SPIRITS] Spirits meeting notes [Draft] Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com This is a multi-part message in MIME format. --------------A49BB5125A16346779A02E66 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Group, Please see attached... -Alec --------------A49BB5125A16346779A02E66 Content-Type: text/plain; charset=iso-8859-1; name="IETF48-SPIRITS minutes.txt" Content-Disposition: inline; filename="IETF48-SPIRITS minutes.txt" Content-Transfer-Encoding: 8bit 48th IETF SPIRITS Working Group Meeting Notes Reported by Alec Brusilovsky. Recorded by Kumar Vemuri, to whom both co-chairs express their deepest appreciation for the job well done. SPIRITS WG met on the morning of Monday, July 31, 2000. There were 110 registered attendees. Chairs: Steve Bellovin, Alec Brusilovsky Agenda 1. Agenda bashing and goals of the session - Alec Brusilovsky - 5 minutes; 2. Progress of Implementation RFC - Hui-Lan Lu - 10 minutes; 3. SPIRITS progress in ITU-T - Hui-Lan Lu - 5 minutes; 4. Discussion on the proposed SPIRITS Architecture - Lev Slutsman - 25 minutes; 5. Discussion on the SPIRITS Protocol Requirements, including: a. Building blocks - and how they define requirements for the Protocol - Lawrence Conroy - 15 minutes b. IN and PINT related SPIRITS Protocol Requirements - Igor Faynberg - 15 minutes; c. SPIRITS Protocol Requirements leading to the Protocol selection - Jörgen Björkner - 15 minutes; 6. Wrap-up - 5 minutes. Steve Bellovin opened the meeting with the announcement and IETF disclaimer, regarding Intellectual Property Rights as they relate to discussions at public meetings at the IETF. 1. Alec Brusilovsky started with the Agenda: Changes in the agenda, since Lev Slutsman could not attend, Igor Faynberg will be the substitute and would cover both Architecture, as well as Protocol Requirements parts. 2. Progress of implementation document, Hui-Lan Lu. Revised version of the implementation RFC is available from the official IETF directory. This version has incorporated all the comments from the mailing list: o Changes to the implementation flows with simpler examples o Better definition of the term "Spirits server" o Automatic Incoming call disposition includes intelligent profiles and private call treatment o Clarification of VersionInfoAck. 3. ITU-T liaison information (Hui-Lan Lu) The last Rapporteur's meeting had no specific discussion of Spirits. SPIRITS related information will be submitted to future ITU-T meetings. 4. Alec B. on Discussion of the Spirits Architecture. Alec talked about WG's charter and milestones, Alec asked everyone to follow a focused discussion on architecture and protocols. Igor (presented) work done with J Gato, L. Slutsman, H. Lu, M. Weissman Introductory comments - issues agreed on: IP side must know the information that comes with the PSTN service requesting messages, and it must know the responses the PSTN expects, and what attributes are required. Architecture picture: Showed Spirits Client near PSTN/IP boundary, and IP connections from this entity to a Spirits proxy via Interface C. This proxy is connected to the Spirits server via Interface B. Similarly, there is a PINT server (a peer of the Spirits proxy - could be co-located with it) that interfaces to the PINT client via Interface A. Igor made a reference to Softswitches as elements that could implement one or more of these services. Interface between Spirits Proxy and the Spirits Client is IN-like. General PINT-aligned interfaces are located between the Sprits proxy and the Spirits server. Registration and subscribe/notify building blocks are used in PINT interface A, this may be needed with some modifications for Spirits with capabilities for DP-arming etc., Some notifications could be subscribed to, but, other out of the blue notifications would also need to be supported. Issue: Is it a requirement that if PINT is implement, Spirits is also implemented? Answer: Not necessary. Subscribe/notify may be commonly used building block in both cases, but there are no requirements that if one is used, then the other must be supported. Interface B does not have to necessarily know details of the PSTN implementation. Issue: Spirits takes into account Wireless IN DPs etc., Brief discussion on IN - the originating and terminating call models then follows: Issue: One of the possible service scenarios: Spirits proxy sends a subscribe for an event to a Spirits Client that then communicates with the SCP which then sends a RequestReportBCSM event to the SSP. When the Spirits server receives an event EDP-N, it then notifies the IP host. With EDP-Rs, the Spirits server can order re-routing of the call, and order IN-related processing of the call. Subscribe Mode can be: Dynamic request (EDP-R) Dynamic notify (EDP-N) Static (TDP-R) Event is any DP. Call disposition: S->P Accept call S->P Reject call, Cause S->P Redirect call, Redirect destination. Question: What does this really give us, since the service has to still know the PSTN information. Why not route the IN parameters to the Spirits server directly? Otherwise, a better way would be to make services network agnostic. Answer: The service is invoked by something happening in the PSTN. This is a given for the Spirits WG. Read from the charter. Charter includes the words "building services to interwork with the PSTN". Chair: Lets stick with the charter. Issue: PINT has direct interfaces to the PSTN Gateway. It is similar with the A interface. how the Spirits message content is "something more" than just plain IN. Issue: Questions concerning notifications, static and dynamic triggering. Trigger management and data management. Event reporting only can be limiting. CS-3 is much more broader. Answer: So far our discussions have been based on IN CS-2, but yes, we should consider CS-3 moving forward. Issue: Relationship between interfaces B and C. Spirits Proxy is more than a proxy since it is doing protocol conversion - between B and C. Is C a combination of both PINT and Spirits protocols? (A and B are integrated into C?) Is there an interface between the PINT server and the Spirits proxy? Answer: There is no need for protocol conversion SIP may be used here. Due to the time limitations the discussion was moved to the mailing list. 5. Building blocks and why they matter, Lawrence Conroy. Issue: Architecture covers "who communicates", other drafts consider "what information does the sender know". There seems to be no information on what message recipients actually do with received events. Building blocks were described Very roughly (work in progress): Server/Service registration Service request processing relationships PINT/Spirits service monitoring. Call Leg Manipulation "service requests" Special resource functions (Data collection, ...) Registration, Relationships. What can be done, who can do it? server and service registration. Request/processing relationships: stateful or stateless nature of the processing. (multi-phase commit etc.,) Monitoring: in PINT, we use Subscribe/Notify/Unsubscribe. There is a need to have the same in Spirits. Service Call Leg Manipulation: e.g. click to dial. add/drop/join/break legs, primitives for this would facilitate conference services hold/resume/transfer, etc. Issue: Spirits must be as close as possible to a PINT system in terms of concept. There is a need for "service context" to refer to previous requests made so there is a "create initial call" request as well. Special Resource/Data Actions: There's a need to collect information to tell the caller what's happening (via Specialized Resources such as Intelligent Peripherals). PINT could use this. e.g. an IP service may request a call to be made to a party in the PSTN to collect info, and the call ends. Spirits could use this to collect data from Internet users. 6. Spirits Protocol Requirements, Jorgen Bjorkner. "How to add Internet Services to Telephony." Issue: Spirits services could be used by other voice networks. Voip services could be easily adjusted to be able to serve PSTN networks. Let us avoid profiles and flavors that do not exist on the Internet. There are no trust relations between PSTN operators and Spirits Service Providers. The focus of this talk is on how to execute Spirits services. Subscription - call customer rep, or http request, IVR etc., Described basic Spirits services. Some services may require user interaction. Protocol Mapping proposal: Map events from the voice network into SIP. Solution: have the two parties involved in the phone call represented as two SIP user agents in the Spirits client, and have the Spirits proxy see these two parties as simple SIP phones (abstracting away PSTN interfaces as far as the Spirits Proxy is concerned). Chair: We may or may not use SIP, but this is not something we can decide right now. Issue: Subscription originates in the IP side, but that would be PINT. (Jorgen agreed). Issue: SS7 has nothing to do with either Spirits or PINT. Issue: Is wireless IN able to provide all the information required for events like "position changed" etc.? WIN and CAMEL standards do exist and could be used. We need a more generic means of carrying information into the Internet. We cannot afford to be too specific, so we are not limited to flavors. Answer: we are not using INAP, we're just using information that is available at the SCP. We use a Spirits protocol to merely carry this information. Chair: We do not need to study the how, let's just stick to "whether this information is available". Issue: Proposal to use standard SIP services in the SIP network for Spirits. Chair: WG has not decided in the use of SIP yet. Henry Sinnreich: talked about the contribution. This is the exact opposite of Voip, its is "IP over Voice". This does everything SIP does, but without SDP. Chair's concluding comments: Architecture there seems to be pretty well done. Requirements draft needs some work by the next meeting. Let us try to get a design team or "team of experts" to get this done. Please let us know who's interested in this work going forward. Meeting is adjourn. --------------A49BB5125A16346779A02E66 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 --------------A49BB5125A16346779A02E66-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Aug 24 11:26:57 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 LAA19132 for ; Thu, 24 Aug 2000 11:26:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 301F144344; Thu, 24 Aug 2000 11:26:53 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from m2-pasarela3.airtel.es (unknown [212.73.32.197]) by lists.bell-labs.com (Postfix) with ESMTP id D5B024433F for ; Thu, 24 Aug 2000 11:26:50 -0400 (EDT) Subject: Re: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Protoco To: spirits@lists.bell-labs.com From: jgato@airtel.es Date: Thu, 24 Aug 2000 17:26:40 +0200 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Version 5.0.2c (Esp.)|8 febrero del 2000) at 08/24/2000 05:26:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA19132 Hi Igor and SPIRITS floks, I guess I should introduce myself (I should have done it before, please accept my apologies). I work for Airtel Móvil (a fix/mobile/ISP company part of the Vodafone-Airtouch group) in Madrid, Spain. I am leading the group responsible for "Network Intelligence" (we have changed the name from "Intelligent Networks"). We both do service development (customised for our specific needs), some consultancy worl for the rest of the company for IN matters and look into evolution and standardisation issues. Below is what I have had time to prepare so far. I hope you find it useful. Please feel free to use it and correct as you consider necessary. Best Regards, Jorge Gato >> In section 4 "IN Requirements", page 4, the requirement to "subscribe" >> to an event from the SPIRITS client is defined as "C : SUBSCRIBE >> ". I think that more parameters could be useful to: >> >> a) Determine if the EDP is going to be armed as EDP-R or EDP-N in >> the IN environment. I understand that both methods to arm events can >> be applicable to SPIRITS services. > >I agree that the explicit requirement for arming DPs is necessary. We >should definitely add that to the requirements. But here are two fine >points: > >1) The requiement that the SCP DPs be dynamically armed from the IP >side is >something that must be supported (because it can be standardized >only by) ITU-T. (I don't see much problem because this is where all >implementations are going.) That is something that Hui-Lan should bring >as the ISOC liaison to the next SG 11 meeting. > >2) I understand that the S..CRIBE/NOTIFY works now much like setting >EDP-N. Now, If a DP is set as an EDP-R, would it mean invocation of >another service or mere continuation of a previous one? (I don't know >the answer. Let us think.) After all, the SPIRITS proxy-to-server >(i.e., SCP) relation is NOT the same as that of the SSP-to-SCP. I don't >see right now a need for EDP-R, but that does not mean there is not any. >Let us discuss. I am not sure if we are talking about the same thing. I understand that the "SUBSCRIBE" message is sent from the SPIRITS Proxy to the SPIRITS client, to be mapped to something to be sent to the Service Control in the SCP. Alternatively the client itself could decide to subscribe to an event without action of the server (this can be the case of automatic call dispositions handled without the server participation). The scenario can be as follows: SPIRITS -> SUBSCRIBE (event) -> SPIRITS Proxy Client | Whatever (out of scope of SPIRITS) | V SCP | RequestReportBCSMEvent (INAP CSX) | V SSP What I mean with setting an EDP-R is that the SPIRITS Server could require to the IN service associated to keep control of the call after the action decided (requiring an EDP-R to be armed in the switching system via the SCP). You are right that for the "milestone" services this is not needed, but it could be useful for future services. An example could an enhanced Internet Call Forwarding where the service wants to make sure the call is accepted by the diverted to party. In this case the SPIRITS service would need to arm EDPs in Request mode to be able to re-route the call in case of failure (for example to the Voice Mail or to another number selected by the user). The difference with the EDP-N case is that the SPIRITS server can take an action involving modifying the related PSTN signalling (like re-routing calls). Thus: a) With EDP-N, when the SPIRITS service receives an event, all it can do is notify the IP Host, update statistical counters or end processing. b) With EDP-R, the SPIRITS service can order re-routing of the call (and eventually could order any action allowed by IN standards, like order applying announcements or creating a multi-leg call). Of course, another option is to always arm EDP-Rs, but this would waste resources in cases where only backwards notification is desired (for example, an abandon EDP-N may be wanted to release resources in the SPIRITS entities). I guess that (if SIP is seleted) some indication about the type of event armed (Request or Notify) chould be needed in SUBSCRIBE and probably NOTIFY. The need to set DP-R has been already been identified in your document. In section 5, there is as reference of the mechanism to register to the SPIRITS service. In page 5 (just before the "Methodology" section) there is a reference of the need to use SUBSCRIBE/NOTIFY PINT building blocks for the purpose of setting DPs/getting DP event notifications. If the complete mechanism to register is put in place, it requires setting a TDP-R in the switch. Thus, there should be a way to subscribe to a Request type event (in this case a static event, a TDP, not related to a specific call). Thus, the SUBSCRIBE message could look like SUBSCRIBE , , where i) Mode could be: - dynamic-request (EDP-R) - dynamic-notify (EDP-N) - static (TDP-R) -I do not see the need to arm TDP-N-. ii) Event could be all CS2 DPs, although I guess not all of them would be used. Since SPIRITS is intended to run services in the IP world to assist PSTN services, I see the following CS-2 DPs as applicable: - origination_attempt_authorized (the SPIRITS service can control call attempts, e.g. to limit calls during specific time periods) - collected_information (for SPIRITS outgoing call screening) - analyzed_information (for SPIRITS outgoing call screening) - (O & T) answer (to release SPIRITS resources after the call is complete) - O_term_seized (to release SPIRITS resources after the call is complete) - (O & T) no_answer (to re-route a call) - (O & T) busy (to re-route a call and for ICW) - route_select_failure (to re-route a call) - (O & T) mid_call (for SPIRITS service to assist a midcall action) - (O & T) abandon (to release SPIRITS service resources) - (O & T) disconnect (to release SPIRITS service resources) - termination_attempt_authorized (needed for SPIRITS "milestone" services) - facility_selected_and_available (could be used alternatively for SPIRITS Internet Caller-ID) However, the only DPs which I see needed for the SPIRITS "milestone" services are: - Termination Attempt Authorized (for Internet Caller-ID). - Facility_selected_and_available (for Internet Caller-ID instead of the TAT). - T_busy (for Internet Call Waiting and Internet Call Forwarding) iii) Parameters should be event specific. I see the need for: - timer (for no answer) - midcall control info (for mid_call) - number of digits (for collected_information) >> >> Besides, I miss more protocol requirements between the SPIRITS client >> and proxy. There is nothing about the signalling flow for the SPIRITS >> service>> (only the event notification and registration parts are >> covered). For example, how will the SPIRITS proxy send the SPIRITS >> server dispositions about an incoming call to the SPIRITS client (so >> it is sent later to the PSTN invoking network)?. I understand that >> these requirements can be covered by existing protocols (e.g. SIP), >> but should not they be specified as a requirement?. > >Absolutely, they should! Please add this material. What I meant here is that the response message to the "Event Notification" is another requirement. In a case where the a) The IP subscriber registers a SPIRITS service. b) A call triggering the SPIRITS service is received (the event is received). c) The call disposition is sent. the signalling flow could look like: |----> REGISTER ----->| SPIRITS |<---- EVENT <-----|SPIRITS Proxy |----> DISPOSITION ---->| Client | | | | | | | V SCP | | V SSP I see missing the call disposition part. Based on the benchmark services, the following ones are needed: a) Accept the incoming call. b) Reject the incoming call. c) Redirect the incoming call. d) Accept the call via VoIP (not included in SPIRITS architecture). Again, we can think of using one message or several messages for each option. I personally would prefer using several messages: a) S->P: <[Accept Call]> b) S->P: <[Reject Call],[Cause]> c) S->P: <[Redirect Call],[Redirection Destination]> This alternative is also quite in the same line that the proposal Jörgen and Sören in "draft-bjorkner-spirits-vsua-00". I understand that the option of accepting the call with VoIP is outside SPIRITS and should not be included here, but still we might want to add an option to the Accept Call case to indicate VoIP. What do you think ?. >> >> Finally, in regards to the Methodology I fully agree on the work needed. >> However, reading the version of ITU-T CS2 specifications that I have >> available (I am not sure if they are the latest ones) the parameters >> indicated are not right. For example, I do neither see "Alerting >> Pattern" being part of TerminationAttemptAuthorized nor >> "DestinationRoutingAddress" (while many parameters are missing). Can you >> double check ?. > >That was just an example, but I strongly suspect I have screwed something >up because I looked at one of my good old files instead of the final text >of Q.1228. That will need to be corrected, of course. The fields which I think are part of the CS-2 TerminationAttemptAuthorized are Call ID begin dPSpecificCommonParameters: ____________ serviceAddressInformation (triggerType, misCallInfo, serviceKey) bearerCapability calledPartyNumber callingPartyNumber callingPartysCategory iPSSPCapabilities iPAvailable iSDNAccessRelatedInformation cGEncountered locationNumber serviceProfileIdentifier terminalType chargeNumber servingAreaID serviceInteractionIndicators serviceInteractionIndicatorsTwo iNServiceCompatibilityIndication uSIInformation uSIServiceIndicator forwardGVNS createdCallSegmentAssociation end dPSpecificCommonParameters ________ dialledDigits callingPartyBusinessGroupID callingPartySubaddress callingFacilityGroup callingFacilityGroupMember originalCalledPartyID prefix redirectingPartyID redirectionInformation routeList travellingClassMark featureCode accessCode carrier serviceInteractionIndicators componentType component componentCorrelationID bcsmEventCorrelationOD CalledPartyBusinessGroupID CalledPartySubaddress CallingPartyBusinessGroupID originalCalledPartyID redirectingPartyID redirectionInformation routeList travellingClassMark _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Aug 24 11:29: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 LAA19155 for ; Thu, 24 Aug 2000 11:29:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C4E844378; Thu, 24 Aug 2000 11:29:50 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id 5751F4433F for ; Thu, 24 Aug 2000 11:29:48 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id LAA00919 for ; Thu, 24 Aug 2000 11:29:47 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id LAA09774; Thu, 24 Aug 2000 11:28:29 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Thu, 24 Aug 2000 11:29:46 -0400 Message-ID: From: "Slutsman, Lev A, ALSVC" To: "'spirits@lists.bell-labs.com'" Subject: RE: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Proto co Date: Thu, 24 Aug 2000 11:29:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA19155 Dear Team, I can not go, but could we have a conference call? Regards, Lev. -----Original Message----- From: jgato@airtel.es [mailto:jgato@airtel.es] Sent: Thursday, August 24, 2000 11:27 AM To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Protoco Hi Igor and SPIRITS floks, I guess I should introduce myself (I should have done it before, please accept my apologies). I work for Airtel Móvil (a fix/mobile/ISP company part of the Vodafone-Airtouch group) in Madrid, Spain. I am leading the group responsible for "Network Intelligence" (we have changed the name from "Intelligent Networks"). We both do service development (customised for our specific needs), some consultancy worl for the rest of the company for IN matters and look into evolution and standardisation issues. Below is what I have had time to prepare so far. I hope you find it useful. Please feel free to use it and correct as you consider necessary. Best Regards, Jorge Gato >> In section 4 "IN Requirements", page 4, the requirement to "subscribe" >> to an event from the SPIRITS client is defined as "C : SUBSCRIBE >> ". I think that more parameters could be useful to: >> >> a) Determine if the EDP is going to be armed as EDP-R or EDP-N in >> the IN environment. I understand that both methods to arm events can >> be applicable to SPIRITS services. > >I agree that the explicit requirement for arming DPs is necessary. We >should definitely add that to the requirements. But here are two fine >points: > >1) The requiement that the SCP DPs be dynamically armed from the IP >side is >something that must be supported (because it can be standardized >only by) ITU-T. (I don't see much problem because this is where all >implementations are going.) That is something that Hui-Lan should bring >as the ISOC liaison to the next SG 11 meeting. > >2) I understand that the S..CRIBE/NOTIFY works now much like setting >EDP-N. Now, If a DP is set as an EDP-R, would it mean invocation of >another service or mere continuation of a previous one? (I don't know >the answer. Let us think.) After all, the SPIRITS proxy-to-server >(i.e., SCP) relation is NOT the same as that of the SSP-to-SCP. I don't >see right now a need for EDP-R, but that does not mean there is not any. >Let us discuss. I am not sure if we are talking about the same thing. I understand that the "SUBSCRIBE" message is sent from the SPIRITS Proxy to the SPIRITS client, to be mapped to something to be sent to the Service Control in the SCP. Alternatively the client itself could decide to subscribe to an event without action of the server (this can be the case of automatic call dispositions handled without the server participation). The scenario can be as follows: SPIRITS -> SUBSCRIBE (event) -> SPIRITS Proxy Client | Whatever (out of scope of SPIRITS) | V SCP | RequestReportBCSMEvent (INAP CSX) | V SSP What I mean with setting an EDP-R is that the SPIRITS Server could require to the IN service associated to keep control of the call after the action decided (requiring an EDP-R to be armed in the switching system via the SCP). You are right that for the "milestone" services this is not needed, but it could be useful for future services. An example could an enhanced Internet Call Forwarding where the service wants to make sure the call is accepted by the diverted to party. In this case the SPIRITS service would need to arm EDPs in Request mode to be able to re-route the call in case of failure (for example to the Voice Mail or to another number selected by the user). The difference with the EDP-N case is that the SPIRITS server can take an action involving modifying the related PSTN signalling (like re-routing calls). Thus: a) With EDP-N, when the SPIRITS service receives an event, all it can do is notify the IP Host, update statistical counters or end processing. b) With EDP-R, the SPIRITS service can order re-routing of the call (and eventually could order any action allowed by IN standards, like order applying announcements or creating a multi-leg call). Of course, another option is to always arm EDP-Rs, but this would waste resources in cases where only backwards notification is desired (for example, an abandon EDP-N may be wanted to release resources in the SPIRITS entities). I guess that (if SIP is seleted) some indication about the type of event armed (Request or Notify) chould be needed in SUBSCRIBE and probably NOTIFY. The need to set DP-R has been already been identified in your document. In section 5, there is as reference of the mechanism to register to the SPIRITS service. In page 5 (just before the "Methodology" section) there is a reference of the need to use SUBSCRIBE/NOTIFY PINT building blocks for the purpose of setting DPs/getting DP event notifications. If the complete mechanism to register is put in place, it requires setting a TDP-R in the switch. Thus, there should be a way to subscribe to a Request type event (in this case a static event, a TDP, not related to a specific call). Thus, the SUBSCRIBE message could look like SUBSCRIBE , , where i) Mode could be: - dynamic-request (EDP-R) - dynamic-notify (EDP-N) - static (TDP-R) -I do not see the need to arm TDP-N-. ii) Event could be all CS2 DPs, although I guess not all of them would be used. Since SPIRITS is intended to run services in the IP world to assist PSTN services, I see the following CS-2 DPs as applicable: - origination_attempt_authorized (the SPIRITS service can control call attempts, e.g. to limit calls during specific time periods) - collected_information (for SPIRITS outgoing call screening) - analyzed_information (for SPIRITS outgoing call screening) - (O & T) answer (to release SPIRITS resources after the call is complete) - O_term_seized (to release SPIRITS resources after the call is complete) - (O & T) no_answer (to re-route a call) - (O & T) busy (to re-route a call and for ICW) - route_select_failure (to re-route a call) - (O & T) mid_call (for SPIRITS service to assist a midcall action) - (O & T) abandon (to release SPIRITS service resources) - (O & T) disconnect (to release SPIRITS service resources) - termination_attempt_authorized (needed for SPIRITS "milestone" services) - facility_selected_and_available (could be used alternatively for SPIRITS Internet Caller-ID) However, the only DPs which I see needed for the SPIRITS "milestone" services are: - Termination Attempt Authorized (for Internet Caller-ID). - Facility_selected_and_available (for Internet Caller-ID instead of the TAT). - T_busy (for Internet Call Waiting and Internet Call Forwarding) iii) Parameters should be event specific. I see the need for: - timer (for no answer) - midcall control info (for mid_call) - number of digits (for collected_information) >> >> Besides, I miss more protocol requirements between the SPIRITS client >> and proxy. There is nothing about the signalling flow for the SPIRITS >> service>> (only the event notification and registration parts are >> covered). For example, how will the SPIRITS proxy send the SPIRITS >> server dispositions about an incoming call to the SPIRITS client (so >> it is sent later to the PSTN invoking network)?. I understand that >> these requirements can be covered by existing protocols (e.g. SIP), >> but should not they be specified as a requirement?. > >Absolutely, they should! Please add this material. What I meant here is that the response message to the "Event Notification" is another requirement. In a case where the a) The IP subscriber registers a SPIRITS service. b) A call triggering the SPIRITS service is received (the event is received). c) The call disposition is sent. the signalling flow could look like: |----> REGISTER ----->| SPIRITS |<---- EVENT <-----|SPIRITS Proxy |----> DISPOSITION ---->| Client | | | | | | | V SCP | | V SSP I see missing the call disposition part. Based on the benchmark services, the following ones are needed: a) Accept the incoming call. b) Reject the incoming call. c) Redirect the incoming call. d) Accept the call via VoIP (not included in SPIRITS architecture). Again, we can think of using one message or several messages for each option. I personally would prefer using several messages: a) S->P: <[Accept Call]> b) S->P: <[Reject Call],[Cause]> c) S->P: <[Redirect Call],[Redirection Destination]> This alternative is also quite in the same line that the proposal Jörgen and Sören in "draft-bjorkner-spirits-vsua-00". I understand that the option of accepting the call with VoIP is outside SPIRITS and should not be included here, but still we might want to add an option to the Accept Call case to indicate VoIP. What do you think ?. >> >> Finally, in regards to the Methodology I fully agree on the work needed. >> However, reading the version of ITU-T CS2 specifications that I have >> available (I am not sure if they are the latest ones) the parameters >> indicated are not right. For example, I do neither see "Alerting >> Pattern" being part of TerminationAttemptAuthorized nor >> "DestinationRoutingAddress" (while many parameters are missing). Can you >> double check ?. > >That was just an example, but I strongly suspect I have screwed something >up because I looked at one of my good old files instead of the final text >of Q.1228. That will need to be corrected, of course. The fields which I think are part of the CS-2 TerminationAttemptAuthorized are Call ID begin dPSpecificCommonParameters: ____________ serviceAddressInformation (triggerType, misCallInfo, serviceKey) bearerCapability calledPartyNumber callingPartyNumber callingPartysCategory iPSSPCapabilities iPAvailable iSDNAccessRelatedInformation cGEncountered locationNumber serviceProfileIdentifier terminalType chargeNumber servingAreaID serviceInteractionIndicators serviceInteractionIndicatorsTwo iNServiceCompatibilityIndication uSIInformation uSIServiceIndicator forwardGVNS createdCallSegmentAssociation end dPSpecificCommonParameters ________ dialledDigits callingPartyBusinessGroupID callingPartySubaddress callingFacilityGroup callingFacilityGroupMember originalCalledPartyID prefix redirectingPartyID redirectionInformation routeList travellingClassMark featureCode accessCode carrier serviceInteractionIndicators componentType component componentCorrelationID bcsmEventCorrelationOD CalledPartyBusinessGroupID CalledPartySubaddress CallingPartyBusinessGroupID originalCalledPartyID redirectingPartyID redirectionInformation routeList travellingClassMark _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Aug 24 12:36:13 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 MAA20208 for ; Thu, 24 Aug 2000 12:36:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 098EF4437D; Thu, 24 Aug 2000 12:36:04 -0400 (EDT) Delivered-To: spirits@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 964B94433A for ; Thu, 24 Aug 2000 12:36:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Aug 24 12:35:21 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 151F644370; Thu, 24 Aug 2000 12:22:12 -0400 (EDT) Delivered-To: spirits@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 C992E44347 for ; Thu, 24 Aug 2000 12:22:11 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA02564; Thu, 24 Aug 2000 12:22:11 -0400 Message-ID: <39A54BAF.478450FA@bell-labs.com> Date: Thu, 24 Aug 2000 12:22:07 -0400 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Protoco References: Content-Type: text/plain; charset=iso-8859-1 Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20208 I should add that, as I received this material from Jorge, I added it to the Requirements presentation in Pittsburgh--with a specific acknowledgement to Jorge for his high-quality contribution. The VGs will soon be published by the IETF in the proceeding and displayed on the SPIRITS Bell Labs page. Jorge kindly agreed to co-author the requirements (and I hope the protocol, too!) with us. A new copy of the draft should be available by November. Igor jgato@airtel.es wrote: > > Hi Igor and SPIRITS floks, > > I guess I should introduce myself (I should have done it before, please > accept my apologies). > I work for Airtel Móvil (a fix/mobile/ISP company part of the > Vodafone-Airtouch group) > in Madrid, Spain. > > I am leading the group responsible for "Network Intelligence" (we have > changed the name from > "Intelligent Networks"). We both do service development (customised for our > specific needs), > some consultancy worl for the rest of the company for IN matters and look > into evolution and > standardisation issues. > > Below is what I have had time to prepare so far. I hope you find it useful. > Please feel free to use > it and correct as you consider necessary. > > Best Regards, > > Jorge Gato > > >> In section 4 "IN Requirements", page 4, the requirement to "subscribe" > >> to an event from the SPIRITS client is defined as "C : SUBSCRIBE > >> ". I think that more parameters could be useful to: > >> > >> a) Determine if the EDP is going to be armed as EDP-R or EDP-N in > >> the IN environment. I understand that both methods to arm events can > >> be applicable to SPIRITS services. > > > >I agree that the explicit requirement for arming DPs is necessary. We > >should definitely add that to the requirements. But here are two fine > >points: > > > >1) The requiement that the SCP DPs be dynamically armed from the IP > >side is >something that must be supported (because it can be standardized > >only by) ITU-T. (I don't see much problem because this is where all > >implementations are going.) That is something that Hui-Lan should bring > >as the ISOC liaison to the next SG 11 meeting. > > > >2) I understand that the S..CRIBE/NOTIFY works now much like setting > >EDP-N. Now, If a DP is set as an EDP-R, would it mean invocation of > >another service or mere continuation of a previous one? (I don't know > >the answer. Let us think.) After all, the SPIRITS proxy-to-server > >(i.e., SCP) relation is NOT the same as that of the SSP-to-SCP. I don't > >see right now a need for EDP-R, but that does not mean there is not any. > >Let us discuss. > > I am not sure if we are talking about the same thing. I understand that > the "SUBSCRIBE" message is sent from the SPIRITS Proxy to the SPIRITS > client, to be mapped to something to be sent to the Service Control in > the SCP. Alternatively the client itself could decide to subscribe to > an event without action of the server (this can be the case of automatic > call dispositions handled without the server participation). > > The scenario can be as follows: > > SPIRITS -> SUBSCRIBE (event) -> SPIRITS > Proxy Client > | > Whatever (out of scope of SPIRITS) > | > V > SCP > | > RequestReportBCSMEvent (INAP CSX) > | > V > SSP > > What I mean with setting an EDP-R is that the SPIRITS Server could > require to the IN service associated to keep control of the call > after the action decided (requiring an EDP-R to be armed in the > switching system via the SCP). > > You are right that for the "milestone" services this is not needed, > but it could be useful for future services. > > An example could an enhanced Internet Call Forwarding where the > service wants to make sure the call is accepted by the diverted to > party. In this case the SPIRITS service would need to arm EDPs in > Request mode to be able to re-route the call in case of failure (for > example to the Voice Mail or to another number selected by the user). > > The difference with the EDP-N case is that the SPIRITS server can take > an action involving modifying the related PSTN signalling (like > re-routing calls). Thus: > > a) With EDP-N, when the SPIRITS service receives an event, all it can > do is notify the IP Host, update statistical counters or end > processing. > > b) With EDP-R, the SPIRITS service can order re-routing of the call > (and eventually could order any action allowed by IN standards, like > order applying announcements or creating a multi-leg call). > > Of course, another option is to always arm EDP-Rs, but this would > waste resources in cases where only backwards notification is desired > (for example, an abandon EDP-N may be wanted to release resources in > the SPIRITS entities). > > I guess that (if SIP is seleted) some indication about the type of event > armed (Request or Notify) chould be needed in SUBSCRIBE and probably > NOTIFY. > > The need to set DP-R has been already been identified in your document. > In section 5, there is as reference of the mechanism to register to the > SPIRITS service. In page 5 (just before the "Methodology" section) there > is a reference of the need to use SUBSCRIBE/NOTIFY PINT building blocks > for the purpose of setting DPs/getting DP event notifications. If the > complete mechanism to register is put in place, it requires setting > a TDP-R in the switch. Thus, there should be a way to subscribe to a > Request type event (in this case a static event, a TDP, not related > to a specific call). > > Thus, the SUBSCRIBE message could look like > > SUBSCRIBE , , > > where > > i) Mode could be: > > - dynamic-request (EDP-R) > - dynamic-notify (EDP-N) > - static (TDP-R) -I do not see the need to arm TDP-N-. > > ii) Event could be all CS2 DPs, although I guess not all of them would be > used. Since SPIRITS is intended to run services in the IP world to > assist PSTN services, I see the following CS-2 DPs as applicable: > > - origination_attempt_authorized (the SPIRITS service can control call > attempts, e.g. to limit calls during specific time periods) > - collected_information (for SPIRITS outgoing call screening) > - analyzed_information (for SPIRITS outgoing call screening) > - (O & T) answer (to release SPIRITS resources after the call is > complete) > - O_term_seized (to release SPIRITS resources after the call is > complete) > - (O & T) no_answer (to re-route a call) > - (O & T) busy (to re-route a call and for ICW) > - route_select_failure (to re-route a call) > - (O & T) mid_call (for SPIRITS service to assist a midcall action) > - (O & T) abandon (to release SPIRITS service resources) > - (O & T) disconnect (to release SPIRITS service resources) > - termination_attempt_authorized (needed for SPIRITS "milestone" services) > - facility_selected_and_available (could be used alternatively for SPIRITS > Internet Caller-ID) > > However, the only DPs which I see needed for the SPIRITS "milestone" > services > are: > > - Termination Attempt Authorized (for Internet Caller-ID). > - Facility_selected_and_available (for Internet Caller-ID instead of the > TAT). > - T_busy (for Internet Call Waiting and Internet Call Forwarding) > > iii) Parameters should be event specific. I see the need for: > > - timer (for no answer) > - midcall control info (for mid_call) > - number of digits (for collected_information) > > >> > >> Besides, I miss more protocol requirements between the SPIRITS client > >> and proxy. There is nothing about the signalling flow for the SPIRITS > >> service>> (only the event notification and registration parts are > >> covered). For example, how will the SPIRITS proxy send the SPIRITS > >> server dispositions about an incoming call to the SPIRITS client (so > >> it is sent later to the PSTN invoking network)?. I understand that > >> these requirements can be covered by existing protocols (e.g. SIP), > >> but should not they be specified as a requirement?. > > > >Absolutely, they should! Please add this material. > > What I meant here is that the response message to the "Event Notification" > is > another requirement. In a case where the > > a) The IP subscriber registers a SPIRITS service. > b) A call triggering the SPIRITS service is received (the event is > received). > c) The call disposition is sent. > > the signalling flow could look like: > > |----> REGISTER ----->| > SPIRITS |<---- EVENT <-----|SPIRITS > Proxy |----> DISPOSITION ---->| Client > | | > | | | > | > | > V > SCP > | > | > V > SSP > > I see missing the call disposition part. Based on the benchmark services, > the > following ones are needed: > > a) Accept the incoming call. > b) Reject the incoming call. > c) Redirect the incoming call. > d) Accept the call via VoIP (not included in SPIRITS architecture). > > Again, we can think of using one message or several messages for each > option. > I personally would prefer using several messages: > > a) S->P: <[Accept Call]> > b) S->P: <[Reject Call],[Cause]> > c) S->P: <[Redirect Call],[Redirection Destination]> > > This alternative is also quite in the same line that the proposal Jörgen > and > Sören in "draft-bjorkner-spirits-vsua-00". > > I understand that the option of accepting the call with VoIP is outside > SPIRITS > and should not be included here, but still we might want to add an option > to the > Accept Call case to indicate VoIP. What do you think ?. > > >> > >> Finally, in regards to the Methodology I fully agree on the work needed. > >> However, reading the version of ITU-T CS2 specifications that I have > >> available (I am not sure if they are the latest ones) the parameters > >> indicated are not right. For example, I do neither see "Alerting > >> Pattern" being part of TerminationAttemptAuthorized nor > >> "DestinationRoutingAddress" (while many parameters are missing). Can you > >> double check ?. > > > >That was just an example, but I strongly suspect I have screwed something > >up because I looked at one of my good old files instead of the final text > >of Q.1228. That will need to be corrected, of course. > > The fields which I think are part of the CS-2 TerminationAttemptAuthorized > are > > Call ID > begin dPSpecificCommonParameters: > ____________ > serviceAddressInformation (triggerType, misCallInfo, serviceKey) > bearerCapability > calledPartyNumber > callingPartyNumber > callingPartysCategory > iPSSPCapabilities > iPAvailable > iSDNAccessRelatedInformation > cGEncountered > locationNumber > serviceProfileIdentifier > terminalType > chargeNumber > servingAreaID > serviceInteractionIndicators > serviceInteractionIndicatorsTwo > iNServiceCompatibilityIndication > uSIInformation > uSIServiceIndicator > forwardGVNS > createdCallSegmentAssociation > end dPSpecificCommonParameters > ________ > dialledDigits > callingPartyBusinessGroupID > callingPartySubaddress > callingFacilityGroup > callingFacilityGroupMember > originalCalledPartyID > prefix > redirectingPartyID > redirectionInformation > routeList > travellingClassMark > featureCode > accessCode > carrier > serviceInteractionIndicators > componentType > component > componentCorrelationID > bcsmEventCorrelationOD > CalledPartyBusinessGroupID > CalledPartySubaddress > CallingPartyBusinessGroupID > originalCalledPartyID > redirectingPartyID > redirectionInformation > routeList > travellingClassMark > > _______________________________________________ > SPIRITS mailing list > SPIRITS@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/spirits _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Aug 25 15:36:43 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 PAA27818 for ; Fri, 25 Aug 2000 15:36:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CC1874439C; Fri, 25 Aug 2000 15:35:40 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8D40D44392; Fri, 25 Aug 2000 14:56:58 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA03453; Fri, 25 Aug 2000 14:56:53 -0400 (EDT) Message-ID: <39A6C175.C94B32A1@cs.columbia.edu> Date: Fri, 25 Aug 2000 14:56:53 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Faynberg Cc: listadmins@research.bell-labs.com, extest@lists.bell-labs.com, ietf-sin@lists.bell-labs.com, iptel@lists.bell-labs.com, pint@lists.bell-labs.com, sip@lists.bell-labs.com, spirits@lists.bell-labs.com References: <39A68C4F.6079EBE7@research.bell-labs.com> <39A6B8A1.19D68E60@bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SPIRITS] Re: [IPTEL] Re: [IETF-PIN] NOTICE: Stripping attachments from list mail. Reply-To: spirits@lists.bell-labs.com Sender: spirits-admin@lists.bell-labs.com Errors-To: spirits-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: IETF SPIRITS Working Group X-BeenThere: spirits@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Faynberg wrote: > > Shaun, > > Many thanks for the information. I believe you have made the right decision. > Furthermore, for all IETF lists (PINT, SIN, SPIRITS, IPTEL) you may and should > disallow even .doc and .ppt attachments. Those who post to these lists must > follow the IETF-required practice of putting documents on their own sites and > sending only pointers via the exploders. To summarise, only text files should be > admitted to the IETF lists. > > Please also feel free to impose a reasonable limit on the size of the > IETF-related e-mail messages. Actually, those probably shouldn't be sent at all to an open-standards list, as they are proprietary formats that are difficult for a significant fraction (i.e., those not using Microsoft operating systems) to read and are themselves likely to contain viruses. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits