From mailman-owner@lists.bell-labs.com Sat Jul 1 05:05:30 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 FAA17897 for ; Sat, 1 Jul 2000 05:05:29 -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 1F276444C5 for ; Sat, 1 Jul 2000 05:04:20 -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: <20000701090420.1F276444C5@lists.bell-labs.com> Date: Sat, 1 Jul 2000 05:04:20 -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 Sun Jul 2 18:30:38 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 SAA10389 for ; Sun, 2 Jul 2000 18:30:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A2D5144339; Sun, 2 Jul 2000 18:30:37 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 33B7544336 for ; Sun, 2 Jul 2000 18:30:36 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id SAA13919 for ; Sun, 2 Jul 2000 18:30:35 -0400 (EDT) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id SAA10316; Sun, 2 Jul 2000 18:32:11 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Sun, 2 Jul 2000 18:30:34 -0400 Message-ID: From: "Slutsman, Lev A, ALSVC" To: "'spirits@lists.bell-labs.com'" Date: Sun, 2 Jul 2000 18:30:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture 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 Dear Team, After reviewing the joined PINT-SPIRIT architecture and Jorgen, Naoto, and Alec responses I came with minor modification and hope it will satisfy all. Figure-1. PINT-SIP Architecture Subscriber PC INTERNET CORE _______________ .................... | _____________ | A . ________________ . | |PINT Client|*******| PINT Server |******* . | |___________| | . |______________| . * | ____________ | . * . * | | SPIRITS | | B . _______*________ . * | | SERVER |*******|SPIRITS Proxy | . * | |___________| | . |______________| . * |_______________| .........*........... * *C * _________________ _______*_________ * | Subscriber | |SPRITS Client | * | Telephone | | * |_________________| |_______________| * * * *E *Trunk *D * ++++++++++*+++++++++++PSTN+++++*+++++++++++++++*++ ________*_________ _______*_______________*__ | SSP(Switch) |***| SERVICE CONTROL FUNCTIOC| |________________|SS7_________________________| 1. Explanations. 2. The Service Descriptions from the Customer Point of view. The purpose of this section is to provide a generic description for each of SPIRITS milestone services: Internet Call Waiting (ICW), Internet Caller-ID Delivery; (CNAME), and Internet Call Forwarding. We assume that: o. The service subscriber has a single telephone line and a PC, which may be, via modem, connected to an ISP, using the same telephone line. o. The user's PC is loaded with the service provider software, which performs a number of functions, such subscription, "dynamic registration", enables the users to provide his/her choice of service/disposition, etc. o. Incoming calls are "trapped" on the subscriber's terminating Local Area Exchange Switch (LEC) that must implement the Termination Attempt Trigger (TAT). o. Service Control Function (SCF), implemented as Service Control Point (SCP), or Service Node (SN), or a combination of both SCP and SN; will grant or reject the termination attempt, and play an announcement for the Subscriber' disposition towards incoming call. We also assume that the SPIRITS services go though the following stages: + Service subscription/cancellation. + "Dynamic" service registration in order to eliminate: 1) feature-interaction with traditional telephone services such as a standard call waiting that allows switching between calling parties; 2) provide extra security, for example providing the new IP address for each session and verification of user's PIN. + Receiving incoming calls. The duration of the session may be defined by an "Expiration" parameter, defined during the "dynamic" service registration. + "Dynamic" service cancellation. This may be done to avoid the interactions between "standard" telephony and the Internet base services. 2.1 SPIRITS ICW Overview. While the specific implementation details my differ from vendor to vendor, the main frame-work of the service must confirmed to the following phases. 1. Service Subscription. The service subscription may be implemented in variety of ways including registration by telephone, registration by mailing an appropriate application, and an registration via the Internet Subscription page provided by the service provider. 2. Dynamic Registration. As the result of the service subscription, the service subscriber will receive/download the appropriate software and install it on his PC. If PIN number is used, the subscriber's PIN will be installed in the local PC database. 3. Session Initiation. The session initiation (see above)is required for two main reasons: 1)to prevent feature interactions, and to provide the extra level of security protection. It is strongly recommended to assign a new user's IP address for each session, and to request a subscriber's confirmation of his/her PIN. In addition, the subscriber may specify the "expiration" time for the new session in the range of 0 to infinity. 4. Handling Incoming Calls. (The user's telephone line is connected to the Internet). ++Call Notification. Normally, upon arrival an incoming call, the subscriber will see a pop-up window on his PC and will need to provide his disposition/choice on how to handle this call. As an alternative, the subscriber may configure his software to send a pre-defined disposition without a pop-up window. The generic subscriber's Choices are listed below. ++Accept Incoming call via the PSTN. This implies that the subscriber is willing to terminate the Internet connection and receive the incoming call over the telephone line. As switching can not be done immediately, and depending on the specific implementation, the caller may hear an opening announcement followed by the "ringing" tone. ++ Reject Incoming Call. The subscriber choose to reject the incoming call. In this case he remains connected to the Internet. The caller will hear the Rejection announcement. ++ Redirection the Incoming call to Voicemail. In this scenario, the subscriber will remain connected to the Internet. One suggested implementation is that SCF granted the Termination Attempt permission to the LEC, and, the switch may use a call forwarding on busy to relay the incoming call to Voicemail. The Caller may hear the opening announcement (music for example), followed by the Specific Voicemail announcement. ++Call Forwarding. To implement this feature, the subscriber should provide in his/her disposition a telephone number to which the incoming call will be transferred. The subscriber remains connected to the Internet. The caller may here an opening announcement, followed by a specific call forwarding announcement. ++ Accept Call by Voice over IP. This very useful feature will allow the subscriber to answer the incoming call via the Internet connection, without disconnecting from ISP. The current SPIRITS architecture has no provisioning for this feature. 2.2 The Internet Call Forwarding Service. In this scenario, the service subscriber shall provide the telephone number to transfer as his disposition on the incoming call notification. This service is actually a subset of the ICW service. 2.3 Internet Caller-ID. In this scenario the subscriber should be able to see both the caller number and his name. The difficulty arises from the limitation of TAT trigger. The AIN does not allow to send the Caller CNAME as a parameter of TAT. One possible implementation of this feature requires the use of database. Thus the SSP will send a message to the SCF to provide the Caller's CNAME and store it locally. The subscriber software will send a request to deliver the CNAME to the user's PC. 3. SPITIS Interfaces. The SPIRITS architecture and interfaces are Depicted in Figure 1 of the Appendix. The following is the list of architectural components: PSTN Domain 1. SSP(subscriber termination LEC office)that implements the TAT trigger. 2. The SCF will typically resides on SCP. It services a dual purpose: 1)to control the switch via SS7 interface; and to control the Internet core elements of the architecture via interfaces D and E. IN Domain 3. Spirits Client. This element is responsible for receiving PSTN request, as well as sending responses back to SCF. 4. The Internet Core consisting of two collocated elements: PINT Server and SPIRITS-Proxy. The PINT Server receives the PINT-like commands from the PINT Client and send them to PSTN for execution via E-interface. The SPIRITS Proxy, that relays the SPRITS request, generated within PSTN to SPRITS Server. 5. PINT Server. This element resides on the subscriber's PC and used for generation PINT like request. 6. SPIRITS Server. This element terminates PSTN requests, provides incoming call notifications, and sends the subscriber choice/disposition back to the SPIRITS Proxy. The rest of this section describes each required interface in more details. 3.1 Interface "A". This interface is used for sending unsolicited PINT request to PINT Server. The principal use of this interface is to "dynamically" register the subscriber (see section 2). As a result of this registration, a)the user's PIN (if used) is verified; b)the user's PC gets a unique IN address which is valid for the duration of the session as define by the user; c)the receiving of incoming calls is enabled. In addition this interface may be used for service subscription. 3.2 Interface "B" This interface is used to notify the subscriber about incoming calls via pop-up window on the subscriber's PC. In addition, the relevant information such as Calling number and CNAME will be displayed on the PC. In the opposite direction, the subscriber choice/disposition is send down to the SPRITS Proxy. 3.3 Interface "C" This interface is used to communicate information from SPIRITS Client to SPIRITS Proxy and vice versa. The SPIRITS Proxy may communicate with the SPRITS SERVER, or it may act as a virtual server, without sending the messages down to the SPIRITS Sever. 3.4 Interface "D". This interface is used to communicate information between SPIRITS Client and SCF. In the direction from SCF to SPIRITS Client. Specifically, the parameters detected in TAT trigger are sent to the SPIRITS Client. The most important for the ICW service are "Call ID" (a mandatory parameters, which specifies the PSTN CALL), and "Alerting Pattern" (an optional parameter specifying how to "ring" the end user). Thus for ICW, it may be desirable to use the PC for "ringing" rather than applying the ringing tone to its line, in order not to interface with standard telephony services such as Voice Call Waiting. In the direction from SPIRITS Client to SCF, the service subscriber choices/Disposition are sent. The SCF "transform" the user's disposition into an appropriate actions, such plying appropriate announcement to the Caller; resuming the suspended call processing in the SSP, etc. 3.5 Interface "E" This interface is provided to send PINT request to SCF for execution. _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Jul 3 12:54:06 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 MAA04765 for ; Mon, 3 Jul 2000 12:54:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF16D44374; Mon, 3 Jul 2000 12:54:03 -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 DAD9044336 for ; Mon, 3 Jul 2000 12:54:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jul 3 12:52:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id A7F9B44351; Mon, 3 Jul 2000 12:39:21 -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 613D144347 for ; Mon, 3 Jul 2000 12:39:21 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA07708; Mon, 3 Jul 2000 11:39:17 -0500 To: "Buller, Jeremy" , SPIRITS list Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA07661; Mon, 3 Jul 2000 11:39:14 -0500 Message-ID: <3960C23E.D2DBB506@lucent.com> Date: Mon, 03 Jul 2000 11:41:34 -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 Original-To: "Buller, Jeremy" , SPIRITS list Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture References: <153BDA136259D311859900A0C99B52632796EB@boca-isbu-nt04.boca.unisphere.com> Content-Type: multipart/mixed; boundary="------------0D8C960800FFB8E99D71D8EA" 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. --------------0D8C960800FFB8E99D71D8EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Buller, Jeremy" wrote: > ... > Below is a couple of diagrams from a draft I was going to > submit. > ... > So if your interested? When > is the deadline by the way? The deadline is July 14. Plenty of time... > .... > Do we really need to know what happens in the PSTN? Your > diagram has interfaces D and E? Lev, Jim, I do agree that interfaces D and E might be important for a comprehensive architectural picture. I would, however, separate all interfaces into two groups: Essential Interfaces (A, B, C) and NonEssential (D, E) Sound like a compromise? > ... > > What is of *real* interest is the action requested (class > of action requested) and responses that should be > available at your interface A and B/C (although I'm a > little unsure of the requirement for an 'explicit' proxy > in the diagram). Again, in opinion one of the advantages of having SPIRITS Proxy in the architecture - it provides a better scalability. > > > For example, if I were interested (which I am) in this > approach for say, the interface between a Soft Switch and > an Application Server (see International SoftSwitch > Consortium) the action requested might be the exactly same > as for IN but the implementation in the PSTN/IN/SoftSwitch > might/ would probably be completely different? But the > implementation is irrelevant because IMO it is out of > scope (the IETF does protocols). For the service logic > in the PSTN of such an implementation I could use an > IN, Application Server or whatever I liked on the other > end. > Sorry to interrupt this discussion thread, but SoftSwitch is completely outside of our Charter. It would be an interesting thread, though! Regards, Alec --------------0D8C960800FFB8E99D71D8EA 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 --------------0D8C960800FFB8E99D71D8EA-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Jul 3 13:00:05 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 NAA04811 for ; Mon, 3 Jul 2000 13:00:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71A374436F; Mon, 3 Jul 2000 13:00:03 -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 D204E44336 for ; Mon, 3 Jul 2000 13:00:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jul 3 12:58:06 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1F69B44352; Mon, 3 Jul 2000 12:44:56 -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 CE0EF44347 for ; Mon, 3 Jul 2000 12:44:55 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA08650; Mon, 3 Jul 2000 11:44:53 -0500 To: "Slutsman, Lev A, ALSVC" , SPIRITS list Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA08641; Mon, 3 Jul 2000 11:44:51 -0500 Message-ID: <3960C38F.91113E88@lucent.com> Date: Mon, 03 Jul 2000 11:47:11 -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 Original-To: "Slutsman, Lev A, ALSVC" , SPIRITS list Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture References: Content-Type: multipart/mixed; boundary="------------0ADBE507449130EBAD8A1FB0" 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. --------------0ADBE507449130EBAD8A1FB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Slutsman, Lev A, ALSVC" wrote: > ... > As for SPIRITS Proxy, this element is needed, because the SPIRITS requests > ,in general, must be terminates at the subscriber's PC. Can we use more general term IP Host, or Internet Appliance. After all, Subscriber's PC represents only certain SPIRITS scenarios. Regards, Alec --------------0ADBE507449130EBAD8A1FB0 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 --------------0ADBE507449130EBAD8A1FB0-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Jul 3 13:39:08 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 NAA05308 for ; Mon, 3 Jul 2000 13:39:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 13A8D44372; Mon, 3 Jul 2000 13:39:07 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 2209C4436F for ; Mon, 3 Jul 2000 13:39:01 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id NAA20400 for ; Mon, 3 Jul 2000 13:38:55 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA26172; Mon, 3 Jul 2000 13:37:47 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jul 2000 13:38:55 -0400 Message-ID: From: "Slutsman, Lev A, ALSVC" To: "'spirits@lists.bell-labs.com'" Subject: RE: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architec ture Date: Mon, 3 Jul 2000 13:38:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 Alec, Hi. I hope you and yours are in good shape. As to you suggestions, I like both of them and will make corresponding changes. Regards, Lev. > ---------- > From: Alec Brusilovsky > Reply To: spirits@lists.bell-labs.com > Sent: Monday, July 03, 2000 12:47 PM > To: Slutsman, Lev A, ALSVC; SPIRITS list > Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS > architecture > > <> > > > "Slutsman, Lev A, ALSVC" wrote: > > > ... > > As for SPIRITS Proxy, this element is needed, because the SPIRITS > requests > > ,in general, must be terminates at the subscriber's PC. > > Can we use more general term IP Host, or Internet Appliance. After all, > Subscriber's PC represents only certain SPIRITS scenarios. > > Regards, > Alec > _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Jul 3 20:52: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 UAA08798 for ; Mon, 3 Jul 2000 20:52: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 6F1384434A; Mon, 3 Jul 2000 20:52:03 -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 8A91044336 for ; Mon, 3 Jul 2000 20:52:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jul 3 20:50:02 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 9685D44351; Mon, 3 Jul 2000 20:36:53 -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 65BA344347 for ; Mon, 3 Jul 2000 20:36:53 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id UAA23765; Mon, 3 Jul 2000 20:36:52 -0400 Message-ID: <396131A3.A9BD7B19@bell-labs.com> Date: Mon, 03 Jul 2000 20:36:51 -0400 From: faynberg@bell-labs.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [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] Minor modifications to Joined PINT-SPIRITS architecture References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 I am jibing. With a few editorial changes (like PINT-SIP is of course PINT-SPIRITS, Subscriber PC changed to IP Host, and Internet Core changed IP Network), we are encorporating this figure in the requirements draft. Let us keep the picture unchanged for the moment. Igor "Slutsman, Lev A, ALSVC" wrote: > > > Dear Team, > After reviewing the joined PINT-SPIRIT architecture and Jorgen, Naoto, and > Alec responses I came with minor modification and hope it will satisfy all. > > Figure-1. PINT-SIP Architecture > Subscriber PC INTERNET CORE > _______________ .................... > | _____________ | A . ________________ . > | |PINT Client|*******| PINT Server |******* . > | |___________| | . |______________| . * > | ____________ | . * . * > | | SPIRITS | | B . _______*________ . * > | | SERVER |*******|SPIRITS Proxy | . * > | |___________| | . |______________| . * > |_______________| .........*........... * > *C * > _________________ _______*_________ * > | Subscriber | |SPRITS Client | * > | Telephone | | * > |_________________| |_______________| * > * * *E > *Trunk *D * > ++++++++++*+++++++++++PSTN+++++*+++++++++++++++*++ > ________*_________ _______*_______________*__ > | SSP(Switch) |***| SERVICE CONTROL FUNCTIOC| > |________________|SS7_________________________| > > _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Jul 3 23:40: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 XAA12347 for ; Mon, 3 Jul 2000 23:40: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 7DB9F4434A; Mon, 3 Jul 2000 23:40: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 98CB644336 for ; Mon, 3 Jul 2000 23:40:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jul 3 23:39:05 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5F3E844351; Mon, 3 Jul 2000 23:25:56 -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 105EF44347 for ; Mon, 3 Jul 2000 23:25:56 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA19469; Mon, 3 Jul 2000 22:25:53 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA19439; Mon, 3 Jul 2000 22:25:51 -0500 Message-ID: <396159CB.9FE7B93B@lucent.com> Date: Mon, 03 Jul 2000 22:28:11 -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 Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture References: <396131A3.A9BD7B19@bell-labs.com> Content-Type: multipart/mixed; boundary="------------B5241592D72474A354749EED" 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. --------------B5241592D72474A354749EED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Team, During our meeting in Adelaide some participants responded to our call for Requirements RFC volunteers. So far, those who responded were REALLY quiet. It is, definitely, time to speak up. Regards, Alec P.S. Please have a safe and happy Fourth of July! (Those of us who celebrate it.) faynberg@bell-labs.com wrote: > I am jibing. With a few editorial changes (like PINT-SIP is of course > PINT-SPIRITS, Subscriber PC changed to IP Host, and Internet Core changed IP > Network), we are encorporating this figure in the requirements draft. > > Let us keep the picture unchanged for the moment. > > Igor > > "Slutsman, Lev A, ALSVC" wrote: > > > > > > Dear Team, > > After reviewing the joined PINT-SPIRIT architecture and Jorgen, Naoto, and > > Alec responses I came with minor modification and hope it will satisfy all. > > > > Figure-1. PINT-SIP Architecture > > Subscriber PC INTERNET CORE > > _______________ .................... > > | _____________ | A . ________________ . > > | |PINT Client|*******| PINT Server |******* . > > | |___________| | . |______________| . * > > | ____________ | . * . * > > | | SPIRITS | | B . _______*________ . * > > | | SERVER |*******|SPIRITS Proxy | . * > > | |___________| | . |______________| . * > > |_______________| .........*........... * > > *C * > > _________________ _______*_________ * > > | Subscriber | |SPRITS Client | * > > | Telephone | | * > > |_________________| |_______________| * > > * * *E > > *Trunk *D * > > ++++++++++*+++++++++++PSTN+++++*+++++++++++++++*++ > > ________*_________ _______*_______________*__ > > | SSP(Switch) |***| SERVICE CONTROL FUNCTIOC| > > |________________|SS7_________________________| > > > > > > _______________________________________________ > SPIRITS mailing list > SPIRITS@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/spirits --------------B5241592D72474A354749EED 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 --------------B5241592D72474A354749EED-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jul 4 15:49:30 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 PAA00343 for ; Tue, 4 Jul 2000 15:49:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 276AA4435E; Tue, 4 Jul 2000 15:49:25 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from boca-isbu-nt04.boca.unisphere.com (exchange.br-unispheresolutions.com [207.36.128.43]) by lists.bell-labs.com (Postfix) with ESMTP id B9E1C44336 for ; Tue, 4 Jul 2000 15:49:23 -0400 (EDT) Received: by boca-isbu-nt04.boca.unisphere.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jul 2000 15:48:38 -0400 Message-ID: <153BDA136259D311859900A0C99B52632796F1@boca-isbu-nt04.boca.unisphere.com> From: "Buller, Jeremy" To: "'Alec Brusilovsky'" , SPIRITS list Subject: RE: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architec ture Date: Tue, 4 Jul 2000 15:48:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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 Hi Alec, > Sorry to interrupt this discussion thread, but SoftSwitch is > completely outside of our Charter. It would be an > interesting thread, though! Mmmmm, OK, how about, 'a thing' that can handle calls, has a call model, may know about points in call and may also have a detection point 'like' mechanism. i.e. those things we probably need to have in the PSTN domain in order to initiate services in the Internet domain. One could maybe consider one variant of this 'thing' to be clever Switch (maybe even, in name, with very soft 'Soft' before it) then I guess it would loosely fall into the PSTN part of the term PSTN/IN. The point I was trying to make was to just raise awareness that the interface discussions of the groups - PINT/SPIRITS WGs and the ISC Application group; seem IMHO in large part to be looking at much the same thing. An issue to consider is whether to follow the PINT paradigm i.e. there is an Executive System in the PSTN and we don't care what it is - a clever switch, IN or a person with a cup of coffee sitting at a switchboard - they are expected to do what is requested of them by the initiating entity in the Internet domain. If we were to follow this paradigm in the SPIRITS case there would exist an Initiative System in the PSTN, but again we don't need to know, or care, what it is. We would only be interested in 'how' it talks to the Internet domain and 'what' it may communicate (the protocol), anything else is quite probably pants. Kind regards, Jim Buller p.s. Happy Independence day to any Americans out there and (humour :) Happy Thanksgiving to any Brits. _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jul 4 22:49:06 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 WAA04170 for ; Tue, 4 Jul 2000 22:49:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D331744346; Tue, 4 Jul 2000 22:49:05 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from relay1.marconi.it (relay1.marconi.it [192.106.52.1]) by lists.bell-labs.com (Postfix) with ESMTP id 121B744336 for ; Tue, 4 Jul 2000 05:09:36 -0400 (EDT) Received: from marconicomms.com (localhost [127.0.0.1]) by relay1.marconi.it (8.9.1a/8.9.1) with SMTP id LAA18310 for ; Tue, 4 Jul 2000 11:05:09 +0200 (MET DST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id C1256912.00324114 ; Tue, 4 Jul 2000 11:08:54 +0200 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Jane Humphrey" To: spirits@lists.bell-labs.com Message-ID: Date: Tue, 4 Jul 2000 08:36:13 +0100 Subject: Re: [SPIRITS] On Joint PINT/SPIRITS Architecture Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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 Igor and Lev I am having a little difficulty in reading your emails due to the fact that my email system has scrambled your diagrams (removal of spaces etc). As a piece of abstract art the diagrams demonstrates an interesting use of lines and text but lacks a little colour however, as a network architecture diagram this scattered approach is useless! Please could you provide the diagrams in a more user friendly form (e.g. an attachment to the email so that the email system cannot change it). Regards Jane Humphrey Marconi Communications _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jul 4 23:24: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 XAA04401 for ; Tue, 4 Jul 2000 23:24:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B992744351; Tue, 4 Jul 2000 23:24:03 -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 D2CCC44346 for ; Tue, 4 Jul 2000 23:24:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jul 4 23:22:26 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8D5BD44351; Tue, 4 Jul 2000 23:09:17 -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 4470944347 for ; Tue, 4 Jul 2000 23:09:17 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA10009; Tue, 4 Jul 2000 22:09:13 -0500 Cc: Tom Limoncelli Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA09978; Tue, 4 Jul 2000 22:09:11 -0500 Message-ID: <3962A765.B75DC01B@lucent.com> Date: Tue, 04 Jul 2000 22:11:33 -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 Original-CC: Tom Limoncelli Subject: Re: [SPIRITS] On Joint PINT/SPIRITS Architecture References: Content-Type: multipart/mixed; boundary="------------D8D5C4F0877279AAABFEAE77" 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. --------------D8D5C4F0877279AAABFEAE77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jane, That might be a quite persistent problem (or feature, if you wish) of this exploder. To prevent long attachments to bog down the network it is being configured to disallow them. BTW, I-Ds have to have pictures in ASCII as well. As much as I would like to see something more expressive, it looks that we will have to stick with "interesting use of lines and text". We have the following choices: 1. Ask Igor and Lev to forward you something more descriptive (PostScript is approved to use for pictures to accompany I-Ds) 2. Ask Tom Limoncelli, our Admin., for any ideas regarding attachments on this list. 3. Try to work with your local mail server administrator. 4. If #3 does not work, sign for any free mail address, @yahoo, @hotbot, etc. and read SPIRITS mail there. 5. Access SPIRITS messages from our archive. Hope this helps, Alec Jane Humphrey wrote: > Igor and Lev > > I am having a little difficulty in reading your emails due to the fact that my > email system has scrambled your diagrams (removal of spaces etc). As a piece of > abstract art the diagrams demonstrates an interesting use of lines and text but > lacks a little colour however, as a network architecture diagram this scattered > approach is useless! Please could you provide the diagrams in a more user > friendly form (e.g. an attachment to the email so that the email system cannot > change it). > > Regards > > Jane Humphrey > Marconi Communications > > _______________________________________________ > SPIRITS mailing list > SPIRITS@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/spirits --------------D8D5C4F0877279AAABFEAE77 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 --------------D8D5C4F0877279AAABFEAE77-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 5 03:27:56 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 DAA18132 for ; Wed, 5 Jul 2000 03:27:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B6DDA44352; Wed, 5 Jul 2000 03:27:55 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id C2BDB44346 for ; Wed, 5 Jul 2000 03:27:53 -0400 (EDT) Received: from jbj (212.28.214.228 [212.28.214.228]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NAVVY5RD; Wed, 5 Jul 2000 09:23:14 +0200 From: =?iso-8859-1?B?SvZyZ2VuIEJq9nJrbmVy?= To: Subject: RE: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture Date: Wed, 5 Jul 2000 09:26:20 +0200 Message-ID: <000201bfe652$515b2de0$e4d61cd4@swipnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <153BDA136259D311859900A0C99B52632796F1@boca-isbu-nt04.boca.unisphere.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 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 I agree with Jeremy, from an IETF SPIRITS viewpoint could PSTN be substituted with ANY other voice handling "thing". This would only affect interface D, which is an implementation issue of one of the interfaces of the SPIRITS client. /Jörgen > -----Original Message----- > From: spirits-admin@lists.bell-labs.com > [mailto:spirits-admin@lists.bell-labs.com]On Behalf Of Buller, Jeremy > Sent: den 4 juli 2000 21:49 > To: 'Alec Brusilovsky'; SPIRITS list > Subject: RE: [SPIRITS] Minor modifications to Joined PINT-SPIRITS > architecture > > > Hi Alec, > > > Sorry to interrupt this discussion thread, but SoftSwitch is > > completely outside of our Charter. It would be an > > interesting thread, though! > Mmmmm, OK, how about, 'a thing' that can handle calls, has > a call model, may know about points in call and may also > have a detection point 'like' mechanism. i.e. those things > we probably need to have in the PSTN domain in order to > initiate services in the Internet domain. > > One could maybe consider one variant of this 'thing' to be > clever Switch (maybe even, in name, with very soft 'Soft' > before it) then I guess it would loosely fall into the > PSTN part of the term PSTN/IN. > > The point I was trying to make was to just raise awareness > that the interface discussions of the groups - PINT/SPIRITS > WGs and the ISC Application group; seem IMHO in large part > to be looking at much the same thing. > > An issue to consider is whether to follow the PINT > paradigm i.e. there is an Executive System in the PSTN > and we don't care what it is - a clever switch, IN or a > person with a cup of coffee sitting at a switchboard - > they are expected to do what is requested of them by the > initiating entity in the Internet domain. If we were to > follow this paradigm in the SPIRITS case there would > exist an Initiative System in the PSTN, but again we don't > need to know, or care, what it is. We would only be > interested in 'how' it talks to the Internet domain and > 'what' it may communicate (the protocol), anything else > is quite probably pants. > > Kind regards, > > Jim Buller > > p.s. Happy Independence day to any Americans out there > and (humour :) Happy Thanksgiving to any Brits. > > > _______________________________________________ > 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 Wed Jul 5 04:27:16 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 EAA18682 for ; Wed, 5 Jul 2000 04:27:16 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CE9DD44352; Wed, 5 Jul 2000 04:27:16 -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 0908944346 for ; Wed, 5 Jul 2000 04:27:15 -0400 (EDT) Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture To: spirits@lists.bell-labs.com From: jgato@airtel.es Date: Wed, 5 Jul 2000 10:26:36 +0200 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Version 5.0.2c (Esp.)|8 febrero del 2000) at 07/05/2000 10:28:00 AM 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 EAA18682 I agree with the PINT-SPIRITS architecture as finally presented by Lev (good job!). My only comment is that all references to Intelligent Network in his email are based on AIN, while in Europe we use ETSI Core INAP CS1. Although the comments made in regards to AIN also apply to CS1, I think that a reference to CS1 terminology would help people in Europe to have a better understanding. The differences are: 1) TAT (Terminating Attempt Trigger) is known as Terminating Attempt Authorised (DP12) in CS1. 2) In CS1, when a DP12 (TAT in AIN) is detected, there is also no standard field to send the CNAME in the InitialDP (sent from the SSP). However a "standard" extension field could be used for this purpose. Regards, Jorge Gató Airtel Móvil _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 5 11:14:05 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 LAA08362 for ; Wed, 5 Jul 2000 11:14:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FC4C443A4; Wed, 5 Jul 2000 11:14:05 -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 378A7443A2 for ; Wed, 5 Jul 2000 11:14:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 5 11:12:46 EDT 2000 Received: by lists.bell-labs.com (Postfix) id BBE7C44351; Wed, 5 Jul 2000 10:59:36 -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 6AE3344347 for ; Wed, 5 Jul 2000 10:59:36 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA00146; Wed, 5 Jul 2000 09:59:34 -0500 Cc: Lev Slutsman , jgato@airtel.es Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA00141; Wed, 5 Jul 2000 09:59:33 -0500 Message-ID: <39634DE1.6D98143F@lucent.com> Date: Wed, 05 Jul 2000 10:01:53 -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 Original-CC: Lev Slutsman , jgato@airtel.es Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture References: Content-Type: multipart/mixed; boundary="------------479A3A6178DFB19154172336" 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. --------------479A3A6178DFB19154172336 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jorge, Very good comment! We already had a conversation with Lev and decided to focus on ITU-T INAP for precisely the same reasons that you outlined. Regards, Alec jgato@airtel.es wrote: > I agree with the PINT-SPIRITS architecture as finally presented by Lev > (good job!). > > My only comment is that all references to Intelligent Network in his email > are based on AIN, while in Europe we use ETSI Core INAP CS1. Although the > comments made in regards to AIN also apply to CS1, I think that a reference > to CS1 terminology would help people in Europe to have a better > understanding. > > The differences are: > > 1) TAT (Terminating Attempt Trigger) is known as Terminating Attempt > Authorised (DP12) in CS1. > 2) In CS1, when a DP12 (TAT in AIN) is detected, there is also no standard > field to send the CNAME in the InitialDP (sent from the SSP). However a > "standard" extension field could be used for this purpose. > > Regards, > > Jorge Gató > Airtel Móvil > > _______________________________________________ > SPIRITS mailing list > SPIRITS@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/spirits --------------479A3A6178DFB19154172336 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 --------------479A3A6178DFB19154172336-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 5 11:52: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 LAA09250 for ; Wed, 5 Jul 2000 11:52:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 22FCE4438D; Wed, 5 Jul 2000 11:52: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 3F71944341 for ; Wed, 5 Jul 2000 11:52:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 5 11:51:12 EDT 2000 Received: by lists.bell-labs.com (Postfix) id CCCE544352; Wed, 5 Jul 2000 11:38:02 -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 8400244347 for ; Wed, 5 Jul 2000 11:38:02 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA19434; Wed, 5 Jul 2000 10:38:00 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA19420; Wed, 5 Jul 2000 10:38:00 -0500 Message-ID: <396356E4.722958FA@lucent.com> Date: Wed, 05 Jul 2000 10:40:20 -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 Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture References: <000201bfe652$515b2de0$e4d61cd4@swipnet.se> Content-Type: multipart/mixed; boundary="------------B7E32B0CEF8E87C6353F9F44" 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. --------------B7E32B0CEF8E87C6353F9F44 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jim, Jörgen, If you are proposing to treat softswitch as 'ANY other voice handling "thing"' - I totally agree. In that case we assume that SS has no special functionality besides being PSTN element. We do not even have to name this element SS. This is well within our Charter. However, SPIRITS charter does not support any SS functionality that is different from "plain" PSTN/IN element. Regards, Alec Jörgen Björkner wrote: > I agree with Jeremy, from an IETF SPIRITS viewpoint could PSTN be > substituted with ANY other voice handling "thing". This would only affect > interface D, which is an implementation issue of one of the interfaces of > the SPIRITS client. > > /Jörgen > > > -----Original Message----- > > From: spirits-admin@lists.bell-labs.com > > [mailto:spirits-admin@lists.bell-labs.com]On Behalf Of Buller, Jeremy > > Sent: den 4 juli 2000 21:49 > > To: 'Alec Brusilovsky'; SPIRITS list > > Subject: RE: [SPIRITS] Minor modifications to Joined PINT-SPIRITS > > architecture > > > > > > Hi Alec, > > > > > Sorry to interrupt this discussion thread, but SoftSwitch is > > > completely outside of our Charter. It would be an > > > interesting thread, though! > > Mmmmm, OK, how about, 'a thing' that can handle calls, has > > a call model, may know about points in call and may also > > have a detection point 'like' mechanism. i.e. those things > > we probably need to have in the PSTN domain in order to > > initiate services in the Internet domain. > > > > One could maybe consider one variant of this 'thing' to be > > clever Switch (maybe even, in name, with very soft 'Soft' > > before it) then I guess it would loosely fall into the > > PSTN part of the term PSTN/IN. > > > > The point I was trying to make was to just raise awareness > > that the interface discussions of the groups - PINT/SPIRITS > > WGs and the ISC Application group; seem IMHO in large part > > to be looking at much the same thing. > > > > An issue to consider is whether to follow the PINT > > paradigm i.e. there is an Executive System in the PSTN > > and we don't care what it is - a clever switch, IN or a > > person with a cup of coffee sitting at a switchboard - > > they are expected to do what is requested of them by the > > initiating entity in the Internet domain. If we were to > > follow this paradigm in the SPIRITS case there would > > exist an Initiative System in the PSTN, but again we don't > > need to know, or care, what it is. We would only be > > interested in 'how' it talks to the Internet domain and > > 'what' it may communicate (the protocol), anything else > > is quite probably pants. > > > > Kind regards, > > > > Jim Buller > > > > p.s. Happy Independence day to any Americans out there > > and (humour :) Happy Thanksgiving to any Brits. > > > > > > _______________________________________________ > > 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 --------------B7E32B0CEF8E87C6353F9F44 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 --------------B7E32B0CEF8E87C6353F9F44-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 5 13:38:07 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 NAA12688 for ; Wed, 5 Jul 2000 13:38:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 53A2E443B0; Wed, 5 Jul 2000 13:38:06 -0400 (EDT) Delivered-To: spirits@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 2752944341 for ; Wed, 5 Jul 2000 13:38:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Jul 5 13:37:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 493B244351; Wed, 5 Jul 2000 13:24:21 -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 186EA44347 for ; Wed, 5 Jul 2000 13:24:21 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA17867; Wed, 5 Jul 2000 13:24:20 -0400 Message-ID: <39636F40.B80A2BA1@bell-labs.com> Date: Wed, 05 Jul 2000 13:24:16 -0400 From: faynberg@bell-labs.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [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] Minor modifications to Joined PINT-SPIRITS architecture References: <000201bfe652$515b2de0$e4d61cd4@swipnet.se> 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 NAA12688 Jörgen Björkner wrote: > > I agree with Jeremy, from an IETF SPIRITS viewpoint could PSTN be > substituted with ANY other voice handling "thing". Well, it is a switch that is a voice handling thing, but for the purposes of PINT and SPIRITS we are dealing with the service control. So, of course one needs to look at voice, and--for that matter--the soft switch, but those are subjects of other IETF WGs, ITU-T, and other bodies. This would only affect > interface D, which is an implementation issue of one of the interfaces of > the SPIRITS client. Right. But note that this interface is to the service control. > > _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 5 16:39:46 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 QAA16542 for ; Wed, 5 Jul 2000 16:39:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DCC704439D; Wed, 5 Jul 2000 16:39:42 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from boca-isbu-nt04.boca.unisphere.com (exchange.br-unispheresolutions.com [207.36.128.43]) by lists.bell-labs.com (Postfix) with ESMTP id 7C2FC44341 for ; Wed, 5 Jul 2000 16:39:39 -0400 (EDT) Received: by boca-isbu-nt04.boca.unisphere.com with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jul 2000 16:38:49 -0400 Message-ID: <153BDA136259D311859900A0C99B52632796F8@boca-isbu-nt04.boca.unisphere.com> From: "Buller, Jeremy" To: "'spirits@lists.bell-labs.com'" Subject: RE: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architec ture Date: Wed, 5 Jul 2000 16:38:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) 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 Hello Alec, Igor I must say, this is a most interesting thread :) but I am not sure if we're talking at crossed purposes here, or, there is an underlying difference of opinion? > Well, it is a switch that is a voice handling thing, but for > the purposes of PINT and SPIRITS we are dealing with the > service control. Exactly! But surely in an abstract sense? With reference to Jorge Gato's previous mail and Alec's mail agreeing there is a difference between implementation terminology in the US and Europe, if one doesn't abstract away from the working terms of the PSTN/IN domain it causes confusion. Agreeing to use any standard in the PSTN domain IMO doesn't help much. > So, of course one needs to look at voice, and--for that > matter--the soft switch, but those are subjects of other > IETF WGs, ITU-T, and other bodies. So according to Alec's mail an agreement has been made to focus on ITU-T INAP in the PSTN/IN domain? Looks like the applicability of this interface protocol may be getting smaller and require mapping. > This would only affect > > interface D, which is an implementation issue of one of the > >interfaces of the SPIRITS client. > > Right. But note that this interface is to the service control. So do you think we should defining this or not? My personal opinion is that I don't believe we should be, thereby following the PINT paradigm. References to what happens prior to the edge of the SPIRITS client IMHO should be only in the most abstract sense e.g. X or Y happens in *very* ambiguous terms. Anything else and IMHO we'd just end up going round and round discussing PSTN/IN service control and not (to me, the more preferable case of) the protocol itself i.e. : Something happens in the PSTN/IN/whatever which results in a need for 'something' to be done in the Internet domain. (not really interesting in its detail) A message is sent that conforms to the SPIRITS protocol. (interesting) I don't know, according to the charter there was supposed to be a drafted protocol by the end of this month, but we're only just getting an architecture tied down, still discussing the boundaries of consideration and the basis (if any) of a protocol itself (to SIP or not to SIP :) So, I'll be the first to make the jump into the dark water and accept that either of you or Steve, or all of you will slap my wrist for presumption with regard to the basis of the protocol. However, I hope it elicits some comments and starts some discussion. Igor, Alec, Steve, I accept we need a vote on a potential basis for this protocol, but please feel free to just consider the actions first and ignore the SIP references. Below is an initial stab at a list of things or classes of things I'd've expected to see in a SPIRITS protocol with reference to possible SIP implementation methods: (Apologies if some of this seems pointless or doesn't make sense, but I'm writing it off the top of my head) Note! I do not distinguish in this list what exactly is in the PSTN. Neither do I specify what is in the Internet domain it may be specialised server or even the subscribers own SIP phone. 1) Registrations/Deregistrations of an Internet entity to the PSTN entity (getting trusted entities 'known' to the PSTN entity) SIP REGISTER - Not sure if the reverse case is also required, it depends who you think should be the controlling entity in the SPIRITS case. Maybe this mechanism could be added to the PINT side of the equation if required. It's a point for further discussion. 2) Registration of available services in the Internet domain - SIP REGISTER again the same point as above about a reverse mechanism perhaps in PINT also applies here. 3) Tranferring control to an Internet Entity - SIP INVITE. 4) Tear down a call which has (as in 3) Internet domain involvement (returning control to the PSTN entity) - SIP BYE. 5) Continue call. The Internet entity has finished doing whatever it was doing and returns control back to the PSTN entity - SIP BYE to terminate involvement - the PSTN entity may continue processing the call. Alternatively, SIP TRANSFER to maintain a monitoring relationship. 6) Request/add a VoIP call leg - SIP INVITE 7) Delete a VoIP call leg - SIP BYE 8) Connect 2 or more call legs - SIP INVITE 9) Transfer call leg - use of SIP Redirction/ Proxy mechanisms or TRANSFER method or BYE/ALSO method. 10) Hold/resume VoIP call leg SIP INVITE(c=0.0.0.0) then reINVITE. 11) Event Notification - PINT like S[]bscribe/Notify or SIP INFO method. 12) Output tones/announcements - SIP 183 Session Progress or INVITE to some IVR box. 13) Digit collection SIP INVITE to a device or SIP INFO (depends on where collection entity is considered to be). 14) Setting service data in the Internet domain from the PSTN - SIP INVITE or REGISTER. 15) DP activation notification to Internet entity. SIP INFO or part of PINT like S[]BSCRIBE/NOTIFY. This would just be a generic mechanism for all such notifications. The service logic should decide what to do with it/ if its relevant. Otherwise, if you need to specify a message format for each DP and thereby you 1) tie yourself to a particular mechanism/terminology, and, 2) Place more explicit handling requirements on either end of the interface. There are others, and I haven't even covered the extended PINT possibilities for doing things like setting DPs changing PICs etc, but I'm guessing this list is probably contentious enough for starters. Please feel free to ignore, add or discard any of the above list or indeed this entire email. I'm just trying fire-up a more detailed discussion. I don't know, maybe in the long run this group will end up producing a list of Informational RFCs defining how these mechanisms can be used to do what this group is trying to do, time will tell. Kind regards, Jim Buller -------------------------------- Unisphere Solutions, 900 Broken Sound Parkway, B12S Boca Raton, FL 33487. USA (+)1 561 923 3132 -------------------------------- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 5 17:18:05 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 RAA17218 for ; Wed, 5 Jul 2000 17:18:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37118443BC; Wed, 5 Jul 2000 17:18: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 D3AE544341 for ; Wed, 5 Jul 2000 17:18:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 5 17:16:04 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 01E3544351; Wed, 5 Jul 2000 17:02:55 -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 AA21D44347 for ; Wed, 5 Jul 2000 17:02:54 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA04960; Wed, 5 Jul 2000 16:02:53 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA04956; Wed, 5 Jul 2000 16:02:53 -0500 Message-ID: <3963A308.AC94BC4B@lucent.com> Date: Wed, 05 Jul 2000 16:05:12 -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 Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture References: <153BDA136259D311859900A0C99B52632796F8@boca-isbu-nt04.boca.unisphere.com> Content-Type: multipart/mixed; boundary="------------1C97DD3A186005032D9F050A" 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. --------------1C97DD3A186005032D9F050A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Buller, Jeremy" wrote: > ... > So according to Alec's mail an agreement has been made to > focus on ITU-T INAP in the PSTN/IN domain? Jim, according to our charter: "...[SPIRITS] services supported by IP network entities can be started from IN (Intelligent Network) requests, as well as the protocol arrangements through which PSTN (Public Switched Telephone Network) can request actions to be carried out in the IP network in response to events (IN Triggers) occurring within the PSTN/IN. ...Definition of any information or data within the PSTN is the responsibility of the ITU-T and so is out of scope for SPIRITS." That is why we deal with ITU-T INAP. To date an official liaison from SPIRITS to ITU-T SG11 was established (Hui-Lan Lu). I am copying Hui-Lan on this message. She might be able to shed more light on SPIRITS-SG11 relations. > > > ... > ... > I don't know, according to the charter there was supposed to > be a drafted protocol by the end of this month, but we're > only just getting an architecture tied down, still discussing > the boundaries of consideration and the basis (if any) of a > protocol itself (to SIP or not to SIP :) We just need to start with the Requirements and then select Protocol, whether it will be SIP or not. > > > So, I'll be the first to make the jump into the dark water > and accept that either of you or Steve, or all of you will > slap my wrist for presumption with regard to the basis of > the protocol. However, I hope it elicits some comments and > starts some discussion. Igor, Alec, Steve, I accept we need > a vote on a potential basis for this protocol, but please > feel free to just consider the actions first and ignore the > SIP references. These are good ideas. Jim, could you convert these thought into an I-D and publish it before 7/14? Regards, Alec --------------1C97DD3A186005032D9F050A 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 --------------1C97DD3A186005032D9F050A-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 5 19:38:07 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 TAA18724 for ; Wed, 5 Jul 2000 19:38:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82D65443A3; Wed, 5 Jul 2000 19:38: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 2EDD344341 for ; Wed, 5 Jul 2000 19:38:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 5 19:36:20 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 8525B44351; Wed, 5 Jul 2000 19:23:11 -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 52E2C44347 for ; Wed, 5 Jul 2000 19:23:11 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id TAA20300; Wed, 5 Jul 2000 19:23:11 -0400 Message-ID: <3963C35D.970EF034@bell-labs.com> Date: Wed, 05 Jul 2000 19:23:09 -0400 From: faynberg@bell-labs.com Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [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] Minor modifications to Joined PINT-SPIRITS architecture References: <153BDA136259D311859900A0C99B52632796F8@boca-isbu-nt04.boca.unisphere.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 "Buller, Jeremy" wrote: > > > > Well, it is a switch that is a voice handling thing, but for > > the purposes of PINT and SPIRITS we are dealing with the > > service control. > Exactly! But surely in an abstract sense? No, no--in the most direct sense. Please see the charter. We have already spent enough time discussing that in two BOFs and the previous meeting, so I am afraid I have nothing to add. I think we ought to move with the real work (to which Jeremy has good proposals in his message) in support of the charter, and this is what I am doing right now. Any conversation about IP telephony or soft switches on this list will take away from the focussed, productive work. > With reference > to Jorge Gato's previous mail and Alec's mail agreeing > there is a difference between implementation terminology > in the US and Europe, if one doesn't abstract away from > the working terms of the PSTN/IN domain it causes > confusion. Agreeing to use any standard in the PSTN domain > IMO doesn't help much. Jorge made a very specific statement, which, in my opinion, is in full agreement with the decision that has been made in SPIRITS. The only international standard on IN is the ITU-T standard. It has already taken care of the regional differences. But, incidentally, in the requirements we are working on, we are referring to the IMT 2000 call model so as to capture WIN, too. > > > So according to Alec's mail an agreement has been made to > focus on ITU-T INAP in the PSTN/IN domain? Looks like the > applicability of this interface protocol may be getting > smaller and require mapping. Not only the agreement has been made, but SPIRITS has started to work with ITU-T on that; we have a liaison both ways. I don't know about the "applicability getting smaller," but the only way to find that out is to examine this applicability. I so far have not seen a single indication that would show that INAP information is insufficient. > > > This would only affect > > > interface D, which is an implementation issue of one of the > > >interfaces of the SPIRITS client. > > > > Right. But note that this interface is to the service control. > So do you think we should defining this or not? My personal > opinion is that I don't believe we should be, thereby following > the PINT paradigm. References to what happens prior to the edge > of the SPIRITS client IMHO should be only in the most abstract > sense e.g. X or Y happens in *very* ambiguous terms. On this point, I completely agree with Jeremy: we should not define this interface. We are making this statement in the requirements. > > > I don't know, according to the charter there was supposed to > be a drafted protocol by the end of this month, but we're > only just getting an architecture tied down, still discussing > the boundaries of consideration and the basis (if any) of a > protocol itself (to SIP or not to SIP :) I can see that all implementations have ALREADY been using SIP, so the issue of selecting a protocol is moot as far as I am concerned. But the job right now is to get the architecture and requirements, and that is what we are doing, and this is how this thread was initiated. > > ... Igor, Alec, Steve, I accept we need > a vote on a potential basis for this protocol, but please > feel free to just consider the actions first and ignore the > SIP references. Ah, it is very kind of Jeremy to associate my name with those of the esteemed chairmen, but I am not one of them so it is really Steve and Alec who should respond. As far as I know there is no vote in the IETF... But I think the moment the requirements are ready, and we agree with them, the choice of the protocol will be natural. > > Below is an initial stab at a list of things or classes of > things I'd've expected to see in a SPIRITS protocol with > reference to possible SIP implementation methods: > > (Apologies if some of this seems pointless or doesn't make > sense, but I'm writing it off the top of my head) > > Note! I do not distinguish in this list what exactly is in > the PSTN. Neither do I specify what is in the Internet domain > it may be specialised server or even the subscribers own SIP > phone. > > 1) Registrations/Deregistrations of an Internet entity > to the PSTN entity (getting trusted entities 'known' > to the PSTN entity) SIP REGISTER - Not sure if the > reverse case is also required, it depends who you > think should be the controlling entity in the > SPIRITS case. Maybe this mechanism could be added to > the PINT side of the equation if required. It's a > point for further discussion. Yes, we have already captured that in the requirements (naturally, without mentioning SIP--we ought to play by the rules). This, incidentally, is a PINT X.0 service. > > 2) Registration of available services in the Internet > domain - SIP REGISTER again the same point as above > about a reverse mechanism perhaps in PINT also > applies here. An interesting issue--we ought to discuss that on line and, possibly, at the meeting. I never thought about that. > > 3) Tranferring control to an Internet Entity - SIP INVITE. Well, here Jeremy is a bit too blunt about SIP again... But then is INVITE really a transfer of control? > > 4) Tear down a call which has (as in 3) Internet domain > involvement (returning control to the PSTN entity) > - SIP BYE. I am more and more disagreing with "control." I think the situation is more complex than either PSTN or Internet having "control" totally. It is more of cooperation, in every single scenario. Look at ICW. While the end-user is making decision on the disposition of the call, the PSTN is actively involved in maintaining the call: the announcements are played to the calling party, SCP sends REFRESH messages to the switch to reset timers. While I perfectly subecribe to the notion that all these are to be invisible to the IP side, they are quite visible to the engineers who must make the thing work. > > 5) Continue call. The Internet entity has finished doing > whatever it was doing and returns control back to the > PSTN entity - SIP BYE to terminate involvement - the > PSTN entity may continue processing the call. > Alternatively, SIP TRANSFER to maintain a monitoring > relationship. Ditto. > > 6) Request/add a VoIP call leg - SIP INVITE > > 7) Delete a VoIP call leg - SIP BYE > > 8) Connect 2 or more call legs - SIP INVITE > > 9) Transfer call leg - use of SIP Redirction/ Proxy > mechanisms or TRANSFER method or BYE/ALSO method. > > 10) Hold/resume VoIP call leg SIP INVITE(c=0.0.0.0) > then reINVITE. Those features have been proposed as PINT building blocks; by themselves, they are not notification, which are supposed to be bread and butter of SPIRITS. > 11) Event Notification - PINT like S[]bscribe/Notify > or SIP INFO method. Ah! Here you are. That we have been writing about. > > 12) Output tones/announcements - SIP 183 Session > Progress or INVITE to some IVR box. > > 13) Digit collection SIP INVITE to a device or SIP > INFO (depends on where collection entity is > considered to be). These two I am not sure about. The way we should define these features, in my opinion, is so that the same protocol will apply to IN (where SCP and Intelligent Peripheral do the job) and the VoIP scenario described above. I asked a similar question at the last meeting (because , and Steve said we may not concentrate on IP telephony specifically in SPIRITS. > > 14) Setting service data in the Internet domain from > the PSTN - SIP INVITE or REGISTER. > > 15) DP activation notification to Internet entity. > SIP INFO or part of PINT like S[]BSCRIBE/NOTIFY. > This would just be a generic mechanism for all > such notifications. The service logic should > decide what to do with it/ if its relevant. > Otherwise, if you need to specify a message > format for each DP and thereby you 1) tie > yourself to a particular mechanism/terminology, > and, 2) Place more explicit handling requirements > on either end of the interface. > This is precisely what we have been tackling. I wish you joined us on this I-D, but we really ought to send it to the IETF now. I hope you will join us for the next issue--as always you have much to contribute. > There are others, and I haven't even covered the extended > PINT possibilities for doing things like setting DPs changing > PICs etc, but I'm guessing this list is probably contentious > enough for starters. No, it is not contentious. It is interesting and useful, although a bit too... blunt. We will have an interesting discussion at the SPIRITS meeting! And I hope you will place all the PINT-related proposals in an I-D to PINT--there you can speak about SIP! > > Please feel free to ignore, add or discard any of the above > list or indeed this entire email. I'm just trying fire-up a > more detailed discussion. I for one thing cannot ignore it--if I did, that would amound to admitting my own ignorance! There are too many good thoughts and useful and relevant suggestions. Igor _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jul 6 11:40:02 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 LAA18946 for ; Thu, 6 Jul 2000 11:40:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9AE4744458; Thu, 6 Jul 2000 11:37:41 -0400 (EDT) Delivered-To: spirits@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 5B69344456 for ; Thu, 6 Jul 2000 11:37:39 -0400 (EDT) Received: from [193.118.192.41] by cundall.co.uk with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 6 Jul 2000 16:35:49 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <3963C35D.970EF034@bell-labs.com> References: <153BDA136259D311859900A0C99B52632796F8@boca-isbu-nt04.boca.unisphere.com > <3963C35D.970EF034@bell-labs.com> Date: Thu, 6 Jul 2000 16:37:10 +0100 To: spirits@lists.bell-labs.com From: Lawrence Conroy Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architecture Cc: faynberg@lucent.com, abrusilovsky@lucent.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 (Really, this concerns building blocks and Archies) Hi folks, I think that "Jim's list" and Igor's comments are not mutually exclusive. Whilst one might argue about using SIP or Some Other Protocol as the "carrier" of state information between entities, the *intent* of an invocation is what Jim's talking about, whilst Igor has been focusing on is the information available in the Initiative System (*great* name!) that in turn defines what information can be passed from the SPIRITS client to the SPIRITS server as parameters of the invocation. These don't really conflict, they're either end of the same pipe. Re. Igor's suggestion that some of the building blocks should be put into a PINT I-D whilst (as Alec suggests) the others should be put into a SPIRITS I-D:: Hmm...we could do that, of course. As long as they are classified as PINT ("invocation down") or SPIRITS ("invocation up") then the list seems to be useful to *both* WGs, so instead I suggest that we keep the two sets in one document, if that's OK. Re. The disparate architecture diagrams: A lot of Jim's comments on the PINT/SPIRITS architecture have been that SPIRITS is a mirror image of PINT, from an architectural perspective. The diagrams in his latest I-D show exactly how much they are reflections of one another. The picture that we've seen from the SPIRITS architecture draft seems to be more specific; I suggest that the SPIRITS/PINT diagram that Jim produced is merely an abstraction of this (albeit rotated by 90 degrees :). Can't this be incorporated into the SPIRITS architecture draft - and if not, then why not? Am I being "brushed by a bus" again? Comments welcome. -- 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 --| _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jul 6 12:52:06 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 MAA20796 for ; Thu, 6 Jul 2000 12:52:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E19444404; Thu, 6 Jul 2000 12:52:05 -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 98016443FC for ; Thu, 6 Jul 2000 12:52:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jul 6 12:50:32 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 4272F44353; Thu, 6 Jul 2000 12:37:23 -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 D863D44347 for ; Thu, 6 Jul 2000 12:37:22 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA13555; Thu, 6 Jul 2000 11:37:20 -0500 Cc: faynberg@lucent.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA13548; Thu, 6 Jul 2000 11:37:19 -0500 Message-ID: <3964B64D.AC5A0A0D@lucent.com> Date: Thu, 06 Jul 2000 11:39:41 -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 Original-CC: faynberg@lucent.com Subject: Re: [SPIRITS] Minor modifications to Joined PINT-SPIRITSarchitecture References: <153BDA136259D311859900A0C99B52632796F8@boca-isbu-nt04.boca.unisphere.com > <3963C35D.970EF034@bell-labs.com> Content-Type: multipart/mixed; boundary="------------A376B76B97FF0EA9ADB3A787" 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. --------------A376B76B97FF0EA9ADB3A787 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lawrence Conroy wrote: > (Really, this concerns building blocks and Archies) > Hi folks, > I think that "Jim's list" and Igor's comments are not mutually exclusive. > > Whilst one might argue about using SIP or Some Other Protocol as the > "carrier" of state information between entities, the *intent* of an > invocation is what Jim's talking about, whilst Igor has been focusing > on is the information available in the Initiative System (*great* name!) > that in turn defines what information can be passed from the SPIRITS > client to the SPIRITS server as parameters of the invocation. > These don't really conflict, they're either end of the same pipe. > Totally agree! Aside from using/not using SIP, (actually Jim and Igor agreed even on that) both of them are focusing on the same invocation process. Regards, Alec --------------A376B76B97FF0EA9ADB3A787 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 --------------A376B76B97FF0EA9ADB3A787-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jul 11 09:50:14 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 JAA00526 for ; Tue, 11 Jul 2000 09:50:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7D8E244373; Tue, 11 Jul 2000 09:50:06 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by lists.bell-labs.com (Postfix) with ESMTP id C18C344336 for ; Tue, 11 Jul 2000 09:50:01 -0400 (EDT) Received: from inser.loniis.spb.su (inser.loniis.spb.su [195.201.37.61]) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id e6BDnwO18733 for ; Tue, 11 Jul 2000 17:49:58 +0400 (MSD) Received: from marat (los.four.loniis.ru [195.201.37.179]) by inser.loniis.spb.su (8.9.3/8.9.3) with SMTP id RAA10049 for ; Tue, 11 Jul 2000 17:49:57 +0400 (MSD) Message-ID: <006d01bfeb3f$8043d7a0$026fa8c0@nio3.loniis.ru> From: "Marat Nourmiev" To: Date: Tue, 11 Jul 2000 17:54:13 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit 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: [SPIRITS] Request for SPIRITS introduction 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 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 From spirits-admin@lists.bell-labs.com Tue Jul 11 11:22: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 LAA03983 for ; Tue, 11 Jul 2000 11:22:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C943E4439A; Tue, 11 Jul 2000 11:22: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 C3E2B44393 for ; Tue, 11 Jul 2000 11:22:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jul 11 11:21:39 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 16F2F44355; Tue, 11 Jul 2000 11:08:30 -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 B8F7644347 for ; Tue, 11 Jul 2000 11:08:29 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA17302; Tue, 11 Jul 2000 10:08:26 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA17287; Tue, 11 Jul 2000 10:08:25 -0500 Message-ID: <396B38FA.E0831A30@lucent.com> Date: Tue, 11 Jul 2000 10:10:50 -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, nourmiev@inser.loniis.spb.su Subject: Re: [SPIRITS] Request for SPIRITS introduction References: <006d01bfeb3f$8043d7a0$026fa8c0@nio3.loniis.ru> Content-Type: multipart/mixed; boundary="------------97E2BC85432A4AE103818040" 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. --------------97E2BC85432A4AE103818040 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 --------------97E2BC85432A4AE103818040 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 --------------97E2BC85432A4AE103818040-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 12 10:45:53 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 KAA25240 for ; Wed, 12 Jul 2000 10:45:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CFB2744369; Wed, 12 Jul 2000 10:45:53 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from mail1.rdc2.pa.home.com (mail1.rdc2.pa.home.com [24.12.106.240]) by lists.bell-labs.com (Postfix) with ESMTP id 9910644345; Wed, 12 Jul 2000 10:33:39 -0400 (EDT) Received: from home.com ([24.3.205.203]) by mail1.rdc2.pa.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000712143338.SDIA1147.mail1.rdc2.pa.home.com@home.com>; Wed, 12 Jul 2000 07:33:38 -0700 Message-ID: <396C81B4.60B45DC0@home.com> Date: Wed, 12 Jul 2000 10:33:24 -0400 From: Herman Silbiger X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Alec Brusilovsky Cc: sip@lists.bell-labs.com, Lawrence Conroy , pint@lists.research.bell-labs.com, SPIRITS list References: <39414575.C030AC3C@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SPIRITS] Re: [PINT] UDP support changed from SHOULD to MUST 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 Annex D to Rec. T.38 specifies SIP/SDP as an optional call establishment metho, T.38. being the Group 3 fax over IP protocol. Support for UDP is mandatory (MUST) in T.38, so it is therefore logically a requirement for SDP. Herman Alec Brusilovsky wrote: > Please see my comments inline. > > Regards, > Alec > > Lawrence Conroy wrote: > > > * UDP support changed from SHOULD to MUST in SIP 2453 bis draft. > > It looks like support for UDP is gradually moving from a SHOULD to a > > MUST in SIP. > > > > In PINT we may not have that assumption. We can have a good reason > > for using TCP only (inline content, security using TLS, ...), so *for > > PINT* I'd prefer to leave this as a SHOULD. > > > > I would like to add to what Lawrence is saying that some SIP applications > might need a more flexible and rapid session set up than others. PINT is a > good example, SPIRITS might as well be another one, assuming that the WG > will decide to use SIP. > > > > > I wonder if the move to a MUST in the core spec will cause grief for > > any other extension or application. > > > > The key point here is ->in the core spec<- > > Looks like the core spec. needs to be more accommodating to the needs of > extensions (PINT). SHOULD is just fine. Why break something that actually > works? > > > > > > > I had the same feeling at the Interim meeting in D.C. when the > > subject of "Busy Line Verification" was raised - there's a lot of > > focus on VoIP, when I can easily imagine SIP being used for a much > > wider set of applications even for "straight" conferences; for > > example, Quake, as Dean suggests. > > Let's imagine an Operator listening in on the sampled Quake audio > > track that I'm conferencing. How long before the Police arrive? An > > over-emphasis on VoIP can lead to bad assumptions, IMHO - SIP is much > > wider than that. > > -- > > lwc@roke.co.uk -- +44 1794 833666 > > ------------------------------------------------------------- > > Herewith a pointless waste of a few lines, stating that > > Roke Manor Research Limited is NOT responsible for my rantings > > and that they would very much like people to sue me rather than > > them if this email contains racist or sexist comments, please. > > Also, I can't do anything; only our lawyers can, so speak to them. > > Oh, and by the way, if our I.T. department has so mangled our > > email system that this has been misdirected, beware that having > > read this far, your eyes are about to fall out from reading > > this highly sensitive information, unless you immediately > > forget that this ever darkened your mailbox. Do it now. > > ------------------------------------------------------------- > > > > _______________________________________________ > > PINT mailing list > > PINT@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/pint _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 12 16:16:10 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 QAA12167 for ; Wed, 12 Jul 2000 16:16:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 986BA44425; Wed, 12 Jul 2000 16:16:06 -0400 (EDT) Delivered-To: spirits@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 80E40443F0 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 0325344359; Wed, 12 Jul 2000 16:01:48 -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 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 Subject: Re: [SPIRITS] Request for SPIRITS introduction References: <006d01bfeb3f$8043d7a0$026fa8c0@nio3.loniis.ru> <396B38FA.E0831A30@lucent.com> Content-Type: multipart/mixed; boundary="------------6CE4AFDA6D1D383A8C124B9B" 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. --------------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-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 12 17:02:07 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 RAA14833 for ; Wed, 12 Jul 2000 17:02:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C69D443FA; Wed, 12 Jul 2000 17:02: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 6A617443F0 for ; Wed, 12 Jul 2000 17:02:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 12 17:01:07 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C9E9F44358; Wed, 12 Jul 2000 16:47:57 -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 9854D44347 for ; Wed, 12 Jul 2000 16:47:57 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA29684; Wed, 12 Jul 2000 16:47:57 -0400 Message-ID: <396CD97C.774754A8@bell-labs.com> Date: Wed, 12 Jul 2000 16:47:56 -0400 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [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] Request for SPIRITS introduction References: <006d01bfeb3f$8043d7a0$026fa8c0@nio3.loniis.ru> <396B38FA.E0831A30@lucent.com> <396CCF38.2F818672@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Spasibo, tovarishch... Igor6 Alec Brusilovsky wrote: > > 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 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jul 13 13:02:21 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 NAA29187 for ; Thu, 13 Jul 2000 13:02:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1799F443A3; Thu, 13 Jul 2000 13:00:48 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id AE2BF44365 for ; Thu, 13 Jul 2000 13:00:38 -0400 (EDT) Received: from jbj (212.28.214.228 [212.28.214.228]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3WF70T8N; Thu, 13 Jul 2000 18:56:03 +0200 From: =?iso-8859-1?B?SvZyZ2VuIEJq9nJrbmVy?= To: Date: Thu, 13 Jul 2000 18:58:03 +0200 Message-ID: <000601bfeceb$82f18800$e4d61cd4@swipnet.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-reply-to: <396CD97C.774754A8@bell-labs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SPIRITS] Internet 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 Content-Transfer-Encoding: 8bit Hi, Here is a draft showing our ideas of how it is possible to realize a SPIRITS solution. Note that it might go a few steps in advance, since a forma protocol decision has not been made yet, but I think it reflects how some of the pre-spirits implementations were built. I have submitted it to internet-drafts@ietf.org, but it might take a while until it is available. I think it was not allowed to have attachments to this list, so it I paste it into the mail below. Thanks /Jörgen ---------------------- Cut Here--------------------- Internet Engineering Task Force J.Bjorkner, S.Nyckelgard Internet Draft Hotsip, Telia Document: draft-bjorkner-spirits-vsua-00.txt July 2000 A SPIRITS solution based on virtual SIP user agents STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document discusses events occurring in a telephony network that could be useful for call related services created in an Internet environment. It also shows one possible implementation of a SPIRITS protocol based on Session Initiation Protocol (SIP) [2]. The SPIRITS working group has not yet done any protocol decisions, so this draft is written for informative purpose showing that the introduction of virtual SIP user agents (SIP UAs) in a SPIRITS client makes it possible to realize the services described in the pre-spirits implementations document [3]. The advantage of introducing SIP UAs in the SPIRITS client is that a SPIRITS proxy and a SPIRITS server then also could be used by any other voice network that natively speaks SIP, for example wireless 3G networks and voice over IP networks. This would also allow the PSTN network to utilize the services created for those networks. The document is not focused on how these services are subscribed for within the telephony network, since there is several appropriate methods to do this from an end users perspective, from calling the customer service to submit a web form. The action taken after this subscription is dependent of the voice network attached to the J.Bjorkner,S.Nyckelgard [1] Internet Draft vsua July 2000 SPIRITS client. This document has the focus on the Internet specific parts of the protocol, which should be voice network independent. 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2. Introduction This document describes a solution to the problem where an event in a telephony network needs to trigger a service that will operate on a particular data within the telephony network associated with the event. The solution described makes it possible to distribute this service logic out from the telephony network to a host on an IP network, or in fact also to a host on the Internet. The solution is coherent with the architecture developed within the SPIRITS working group and proposes a solution based on SIP (Session Initiation Protocol) [2]. There are two reasons to use SIP as a foundation for the SPIRITS protocol: By using SIP will it be possible for SIP speaking voice networks to utilize the SPIRITS services; SIP is designed for Internet use with respect to scaling and security and contains necessary placeholders for information related to voice calls. The solution described fits in to the SPIRITS architecture defined by the SPIRITS working group shown in Figure 1. The interfaces defined with this solution are B and C. The interface D is not described in this document, since it is dependent on the signaling protocols used in the underlying network. The D interface only affects the SPIRITS client implementation according to this proposal and leaves the interfaces B and C unaffected. If one would like to use the already existing service protocols defined for PSTN to talk to IP based hosts, then these protocols can be tunneled as they are by using the protocols defined in the IETF SIGTRAN working group. Those protocols are however not designed for an Internet environment with respect to trust relations and transport conditions, so therefore could it be useful to map functionality from these protocols to something more Internet friendly. Another disadvantage with this method is that these protocols exist in different national flavors in different countries and even in some cases differs among the networks owned by a single operator. On the Internet exists no flavors of a standard, and it is important that a SPIRITS server could work together with several operators in different countries, without having to install special software to make it work. These problems are solved by a protocol mapping as described in this document. J.Bjorkner,S.Nyckelgard [2] Internet Draft vsua July 2000 +-----------+ | SPIRITS | | Server | +-----+-----+ | B +-----------+ | SPIRITS | | Proxy | +-----+-----+ | C +-----------+ | SPIRITS | | Client | +-----+-----+ | D +-----------+ | Voice net | | service | | function | +-----------+ Figure 1. The basic idea with this proposal is to show that it is possible to create a solution which make the PSTN phones to appear as if they were SIP phones to the SPIRITS server. The motivation for this is that there will soon be a large number of innovative services that will be deployed for SIP networks. If a PSTN could behave as a SIP networks from a signaling point of view, it could easily make use of these services. Another rationale to use telephony services implemented in SIP is that SIP will be the signaling protocol used for the all IP 3G wireless networks. The functions provided by service protocols used in an IN environment in today's PSTN networks differs depending on which version and flavor of the IN protocol that is used. Instead of focusing on the particular functions and the naming of the functions within the different IN protocols, a set of general functions of interest for a SPIRITS service are defined and explained in the next section. The set of general functions is a subset of capabilities of the current IN protocols. They provide a balanced tradeoff between complexity and functionality. Having this signaling protocol agnostic view ensures that no PSTN specific behavior is built into the SPIRITS protocol, which is essential in order to make SPIRITS useful also for other voice networks than PSTN. 3. Telephony events that could trigger a SPIRITS server J.Bjorkner,S.Nyckelgard [3] Internet Draft vsua July 2000 This section lists events occurring in a voice network that could trigger a request from the voice network to a SPIRITS server. It also outlines the information that is passed between the SPIRITS client and the SPIRITS server. Parameters and formats are subjects for a follow-up draft. The events are divided into three different categories: call origination, call termination and non-call related. C->S: denotes information passed from the SPIRITS Client to the SPIRITS server. S->C: denotes information passed in the opposite direction. 3.1 Call origination events 3.1.1 Event O1 (Call initiation) C->S: call identifier, calling party address, called party address, dialed address, S->C: response code, call identifier, [calling party address, called party address, dialed address] This event is triggered when a user has filled out a complete address (i.e. dialed a number) but before a route has been selected for the call. A normal response from the SPIRITS server carries the same parameter fields as the query but the SPIRITS server may have changed any data field(s) except 'call identifier'. The returned data is used for routing the call in the voice network. An alternative response may indicate to the SPIRITS client to complete the call as dialed or to reject the call. Services possible to create with this event are e.g. Call Barring, Speed Dialing, VPN services, Number Portability etc. This event maps to a SIP Invite request. 3.2 Call termination events 3.2.1 Event T1 (Call received) C->S: call identifier, calling party address, called party address, dialed address, S->C: response code, call identifier, [calling party address, called party address, dialed address] This event is triggered when a call is received at the switch servicing the callee, before the phone starts ringing. J.Bjorkner,S.Nyckelgard [4] Internet Draft vsua July 2000 The response from the SPIRITS server may indicate to the SPIRITS client to make the callee's phone ring, to redirect the call to another destination or to reject the call. Services possible to create with this event are: Conditional Redirection, Call Filtering, Internet Call Waiting, Internet Caller Identification, etc. This event maps to a SIP invite request. 3.3 Call progress informative events 3.3.1 Event I1 (Call failed) C->S: call identifier, calling party address, called party address, dialed address, reason of failure S->C: This event is sent if a call for some reason failed to be set up. This event maps to a SIP 503 Service Unavailable response. 3.3.2 Event I2 (Callee busy) C->S: call identifier, calling party address, called party address, dialed address S->C:-- This event is sent if the called party is busy due to an ongoing phone call. This event maps to a SIP 486 Busy Here response. 3.3.3 Event I3 (Call rejected) C->S: call identifier, calling party address, called party address, dialed address, reason of rejection S->C:-- This event is sent if the called party rejects an incoming call for some reason. This event maps to a SIP 603 Decline response. 3.3.4 Event I4 (Call terminated) J.Bjorkner,S.Nyckelgard [5] Internet Draft vsua July 2000 C->S: call identifier, calling party address, called party address, dialed address S->C:-- This event is sent if any of the calling parties terminates the call by hanging up. This event maps to a SIP Bye request. 3.4 Non call related events 3.4.1 Event N1 (User logged on) C->S: user id S->C: -- This event is sent when a user logs on to his phone, i.e. turns on his cell phone. This information is useful for intelligent routing services. This event maps to a SIP Register request. 3.4.1 Event N2 (User logged off) C->S: user id S->C: -- This event is sent when a user logs off from his phone, i.e. turns off his cell phone. This information is useful for intelligent routing services. This event maps to a SIP Register request. 3.4.1 Event N3 (Position changed) C->S: user id, spatial location S->C: -- This event is sent when a user updates his position in the network. His geographical coordinates for his current position are sent within the event. This information is useful for intelligent call routing services. Note. It is probably good to have the option to send this event slightly before an event that might have use of the information, J.Bjorkner,S.Nyckelgard [6] Internet Draft vsua July 2000 instead of constantly sending these messages when an user is moving around. This event maps to a SIP Register request. 4. Architecture Since telephony calls usually involves two ore more parties is it proposed that the SPIRITS client actually consists of two logical entities representing the calling and called party. These entities could be viewed as virtual phones, or virtual users. Those entities are called user agents (UA) throughout this document. The user agent representing the calling party is named user agent A (UAA), and the UA representing the called party is named user agent B (UAB). Depending on if the SPIRITS client is residing in the originating end of the network or terminating end of the network are these named originating or terminating user agents (OUA, TUA). The idea is that when a call is to be set up from a user subscribing to a SPIRITS service is a UAA corresponding to the calling party created within the SPIRITS client. At the same time is a UAB set up to represent the called party. An event is sent from the UAA to the SPIRITS proxy, which could modify the call setup information before it is sent to the UAB. The SPIRITS proxy will then remain within the signaling path between the UAA and the UAB throughout the call to receive call related events. The advantage with this setup is that the UAA and UAB don't have to reside within the same SPIRITS client for the services residing in the SPIRITS proxy to work. The same SPIRITS proxy could then serve voice networks of a more distributed nature. Some services, for example Internet Call Waiting, requires some end user interaction. In this case will the SPIRITS proxy forward the incoming event to the SPIRITS server for user notification. If a response is not received from this server within a certain amount of time could the proxy process the message according to some pre- defined logic. The most complex scenario is when a user who has an originating SPIRITS service is calling a user who has a terminating SPIRITS service. In this case will the call informative events pass flow through two SPIRITS servers as shown in Figure 2. J.Bjorkner,S.Nyckelgard [7] Internet Draft vsua July 2000 +----------------+ +----------------+ | SPIRITS proxy | | SPIRITS proxy | +----------------+ +----------------+ | | | | /|\ | /|\ | | \|/ | \|/ | | | | +-+----+--+----+-- +-+----+--+----+-+ | |OUAA| |OUAB| | | |TUAA| |TUAB| | | +----+ +----+ | | +----+ +----+ | | SPIRITS Client | | SPIRITS client | +----------------+ +----------------+ | | 0---0 +-----------+ +-----------+ 0---0 /_\-->-| Exec. Syst|------------->-------|Exec. Syst.|-->-/_\ +-----------+ +-----------+ Orig. Side Term. Side Figure 2. 5. Transport protocol This document proposes to use SIP as a transport protocol for the SPIRITS messages. One reason for this is that it designed to work in an environment consisting of the entities described in the SPIRTIS architecture. As the next section will show could SIP be used as it is without any new extensions to be able to create the services described in the pre-SPIRITS implementations document [3]. Instead needs the behavior it the entities be specified, and the encoding of the necessary information to be transported from the SPIRITS client to the SPIRITS proxy and servers. 6. System components This section gives a description of the components necessary to create a SPIRITS service and their behavior. 6.1 Executive system This is the logic in the voice network responsible for setting up a call, in a PSTN network is this corresponding to a switch. The executive system is required to report all events occurring in the J.Bjorkner,S.Nyckelgard [8] Internet Draft vsua July 2000 telephony network necessary to create SPIRITS services to the SPIRITS client. The executive system has the knowledge that a user is subscribing to a SPIRITS service and is invoking a SPIRITS client for all inbound and outbound calls for this user. 6.2 SPIRITS Client The SPIRITS client is the bridge between the voice network's service function and the SPIRITS services created in an IP environment. The SPIRITS client have a default behavior on inbound calls that triggers it to send out requests to a SPIRITS proxy on the IP network. Its handling of the call is determined from the responses of these requests. Therefore is there no need for the SPIRITS client to have any knowledge of the service executed in the IP network. The SPIRITS client could be viewed of having two sides, one inbound side and one outbound. An inbound call to a user having a SPIRITS service is associated with the inbound side of the client and that UA, the UAA. Depending of the type of service could the SPIRITS client stay involved in the signaling path for the rest of the call. In this case is an outbound UA, UAB, associated with the connected address. In the case of a service that wants to stay within the signaling path is the invite message forwarded to the UAB, with a request URI containing the number to connect the inbound call leg with. The address of UAB is carried in the route: header of the initial Invite request. 6.2.1 SPIRITS Client UA Outbound Requests The UAA sends a SIP Invite to the SPIRITS proxy. The request URI contains the dialed inbound number, the from: field the calling party's number and the to: field the originally dialed number. The to: field could differ from the request URI if any redirection had occurred in the voice network. The UAA also inserts a route: header indicating the address of the UAB associated with this call. The UAA or UAB sends a BYE request when an active call associated to the client is terminated to the proxy. 6.2.2 SPIRITS Client UA Inbound Requests When a SIP Invite is received by the UAB makes the SPIRITS client the executive system to create an outbound call leg to the telephone number in the request URI. The progress of setting up this call leg is reported back to the SPIRITS proxy with appropriate provisional responses. When the called party on this leg answers the phone is a 200 OK sent back through the proxy to the UAA. If the Invite contained a record-route header would all further requests be sent according to these routes. By this could a SPIRITS proxy ask to receive the BYE message sent when the call is terminated. J.Bjorkner,S.Nyckelgard [9] Internet Draft vsua July 2000 If the Invite message contains a replaces: header would the SPIRITS client tear down any ongoing call leg towards the telephone number and call ID indicated in this header. The replaces header is introduced in the SIP Call Control Services draft [4]. When a Bye request is received by any UA is the call leg associated with this UA terminated by a signal from the SPIRITS client to the executive system. 6.2.3 SPIRITS Client responses A number of different SIP responses could be received to the invite sent by the UAA. The action to these responses is described below. 200 OK, indicates that the SPIRITS client should signal down to the executive system to connect inbound call leg with the call leg corresponding to the UAS. The SPIRITS client will stay associated with the call until it ends. 302 Moved Temporarily, the SPIRITS client tells the executive system to redirect the incoming call to the telephone number in the contact: field of the response. The SPIRITS client is released from the call. 404 Not found, indicates that the SPIRITS client should signal down to the executive system to connect the call to the telephone number of the inbound call. The SPIRITS client is released from the call. 603 Decline, tell the executive system to reject the inbound call. The SPIRITS client is released from the call. 6.3 SPIRITS proxy The SPIRITS proxy is the entity that implements the SPIRITS services. The behavior is similar to a SIP redirect/proxy server since it performs some action based on the request URI of an incoming request and either responds back or forwards the invite to the next hop server. In the case of a SPIRITS proxy would the next hop server always be the UAB since the UAA always inserts a route header containing its address. If there is need for user interaction would the proxy know if a user is online by the register messages sent from the user to the proxy. In this case could a request be sent to the user before the incoming request is forwarded or responded to. 7. Call flows This section shows how the services described in the pre spirits implementations document could be realized according to the proposed solution. The target services according to the SPIRITS charter are: Internet Call Waiting, Internet Caller Identification and Internet Call Forwarding. The SPIRITS protocol should not be hard wired to J.Bjorkner,S.Nyckelgard [10] Internet Draft vsua July 2000 just fit these services, the protocol is a useful tool for people implementing services in a SPIRITS proxy or SPIRITS server. These examples show the involved message transactions. It needs to be defined how to encode the information to be transported within the messages. 7.1 Internet Call Waiting Internet Call Waiting (ICW) is an example of a terminating service which is executed when the call signaling is reaching the executive telephone system responsible for the called party. Since ICW is just involved during the call setup phase is there no need for the SPIRITS server to be involved in the signaling path after the call has been established. The following steps are invoked in the service execution. 1. The inbound call setup signaling is received at the receiving executive system. This system associates the called number with a SPIRITS customer and invokes a SPIRITS client. This invocation is out of scope for this working group, and is dependent on the signaling mechanisms used in the voice network. 2. The SPIRITS client creates an UAA and UAB which will be used to control the call setup in the voice network. 3. The UAC send a SIP Invite message to the SPIRITS Proxy. If a user is online would he have sent a SIP Register to the SPIRITS proxy that contained the IP host he is running his ICW software on. In this case would the proxy forward the Invite message to the ICW client (SPIRITS server). If he were not registered with the SPIRITS proxy would the proxy respond with a 404 Not Found message to the UAA. This would cause the SPIRITS client to signal back to the executive system to continue the call setup with the dialed number. 4. If the user were online would he receive an Invite message. This invite message contains the calling party's number in the from: field that could be used for caller identification. The ICW software (SPIRITS server) would show a window telling the user that there is an incoming call. He could then have the option to reject, accept or redirect the call to another number. In the case of rejection would the SPIRITS server return a 603 Decline response to the proxy. This would cause the proxy to respond with the same message to the UAA. If the call is accepted is the Invite forwarded to the UAA contained in the route: header. This invite will contain a replaces: header to indicate that the ongoing call should be terminated. The call ID for this ongoing were fetched by the SPIRITS proxy during the call setup of this ongoing call. In this case would the UAB cause the executive system to disconnect any connected voice calls for this user and after that connect the inbound call that was accepted. If the user whishes to redirect the call to any other answering place, for example a soft phone on his PC or a cell phone would a 302 Moved Temporarily be returned with the phone number to redirect to in the J.Bjorkner,S.Nyckelgard [11] Internet Draft vsua July 2000 contact: field of the answer. This would cause the executive system to set up the inbound call to this telephone number. 5. When a response is received at the UAA is action taken according to above. This would cause the call to be connected and make a phone to start ringing. 7.2 Internet Caller Identification The Internet Caller Identification (ICI) service is a somewhat simplified version of Internet Call Waiting. The message flow is the same as for that service, except that the UAC immediately connects the call. The Invite message sent out from the UAA would be received by the ICI software that a user have registered with the SPIRITS proxy. This message would cause a window to pop up which displays the name and number of the calling party. This information is fetched from the from: field of the Invite message. 7.3 Internet Call Authorization This is an example of a more advanced call barring service which is an originating service. The idea is that a user can set up rules which regulates which number that can be dialed or not. This set of rules is stored in the SPIRITS server. If a number is dialed that is blocked by the rule set could the SPIRITS server alert the user that this is the case, and ask for an authorization code. This would cause a software to pop up a window asking for the code. If the right code were entered would the call setup continue. The message flow for this service is as follows: 1. All outbound calls for a user be detected by the executive system. The dialed number would be sent to the SPIRITS client that creates an UAA for this call. 2. An Invite message is sent to the SPIRITS proxy. This proxy contains an access control list of the numbers that this user is allowed to call. If there is a granted number is a 200 OK sent back to the UAA. If it is a number that is not permitted to call is the action dependent of if the user is running his ICA application or not. If the user were not logged on would the proxy return a 603 Decline to the UAA. 3. If the user is logged on, i.e. have registered with the proxy is the Invite forwarded to the application. In normal SIP scenarios is the client authenticating himself for the server, i.e. authentication is necessary to send a request. In this scenario is the opposite necessary, authentication is necessary to send a response. This could be done by inserting an WWW-authenticate header containing a challenge in the Invite message sent from the proxy. This would cause a window to pop up asking for an authorization code and also displaying the dialed from and to numbers. From this code is a response calculated and returned in a authentication header in a 200 OK response back to the proxy. The J.Bjorkner,S.Nyckelgard [12] Internet Draft vsua July 2000 proxy checks whether this was a valid authentication, and if it was the case forwards the Invite to the UAB to set up the call. Otherwise is a 603 Decline returned to the UAA. 7.4 Internet Call Distribution This is an example of how an automatic call distribution service could be built on top of the tools described in this document. A call distribution service is a service that selects a termination number depending on some built in logic, independent of the dialed number. The service is a terminating service. This service is also involved during the whole call setup and the call itself since it needs to know if a call was successfully set up and when a call ends. The steps involved during a call invoking such a service is described below. 1. An inbound call is received by the executive system in the voice network. The executive system has the knowledge that this dialed number has an associated SPIRITS service. 2. The executive system invokes the SPIRITS client and provides it with the called and calling party number. 3. The SPIRITS client creates a UAA and UAB. The UAA is associated with in inbound call leg to the executive system. The UAB will be the entity responsible to create an outbound call leg from the executive system towards a recipient of the call. The recipient is of the call determined by the SPIRITS proxy according to some built in logic. These two user agents could be viewed as mirrors of the phones involved during the call. 4. The UAA sends an Invite message to the SPIRITS proxy. The dialed number is inserted in a tel: URL in the request URI of the message. The proxy looks performs its logic based on the values of for example the request URI and the from: field. Based on this information is a new termination number determined which is inserted in the request URI of the invite message before it is forwarded. Since the SPIRITS client needs to get this information to the UAB, is a route header containing the address of the UAB inserted in the Invite message sent to the SPIRITS proxy. This will force the proxy to forward the Invite to the UAB. The proxy also inserts a record- route header in the Invite message before it is forwarded, to ensure that all further requests is sent through the proxy. 5. The UAB receives the Invite message. The request URI contains the number to be called. The UAB uses this number and makes the executive system to contact this number. The executive system sends back status information to the SPIRITS client regarding the call setup progress. These messages are mapped to appropriate SIP provisional responses and are sent back from the UAB via the proxy to the UAA. If the call setup fails or takes too long time could the proxy send a Cancel to the UAB to terminate the call setup attempt, and send a new Invite to the UAB with a new number to try. By this could call forward on no answer be created. J.Bjorkner,S.Nyckelgard [13] Internet Draft vsua July 2000 6. When the executive system reports back to the SPIRITS client that the intended destination has been reached is a 200 OK sent back from the UAB through the proxy to the UAA. When this is received by the UAA will the SPIRITS client report down to the executive system that the call should be connected 7. When the calling party hangs up will a BYE message be sent from either the UAs, through the proxy, to the other UA. This is useful if the service in the proxy needs this to free up some resources or create some statistics. From the view of the proxy is this call setup looking like any call setup between two SIP endpoints. This has the advantage that the same service proxy could be used for both a SIP network and a SPIRITS enabled telephony network. The SPIRITS client is performing basically the same task as a PINT server is doing. The PINT server is creating two call legs in the PSTN and ties them together. In this case we already have one of the legs, and creates another which then is tied together with the first one. 8. Security Considerations Since the transactions occurring between the SPIRITS client and SPIRITS proxy contain sensitive data is it recommended that hop-to- hop encryption or a secure transport layer be used for this communication. These mechanisms are described in section 13 of [2]. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, M., et al., "SIP: Session Initiation Protocol", RFC 2543, March 1999 3 Lu, H., et al., "Pre-Spirits Implementations of PSTN-initiated Services", IETF Internet Draft draft-ietf-spirits- implementations-00.txt, May 2000 4 Schulzrinne,H., Rosenberg,J., "SIP Call Control Services (draft 1)",IETF Internet Draft draft-ietf-mmusic-sip-cc-01.txt, June 1999, www.cs.columbia.edu/~jdrosen 10. Acknowledgments 11. Author's Addresses J.Bjorkner,S.Nyckelgard [14] Internet Draft vsua July 2000 Jorgen Bjorkner Hotsip AB Barnhusgatan 16 SE-111 23 Stockholm Sweden Phone: +46 70 666 23 26 Email: Jorgen.Bjorkner@Hotsip.com Soren Nyckelgard Telia Research AB SE-123 86 Farsta Sweden Phone: +46 31 89 77 71 Email: Soren.M.Nyckelgard@telia.se J.Bjorkner,S.Nyckelgard [15] Internet Draft vsua July 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into J.Bjorkner,S.Nyckelgard [16] _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jul 13 16:40:05 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 QAA18811 for ; Thu, 13 Jul 2000 16:40:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ECB4844361; Thu, 13 Jul 2000 16:40: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 8670144336 for ; Thu, 13 Jul 2000 16:40:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jul 13 16:38:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 92A3A44358; Thu, 13 Jul 2000 16:25:27 -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 41F5744347 for ; Thu, 13 Jul 2000 16:25:27 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA21255; Thu, 13 Jul 2000 15:25:22 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA21251; Thu, 13 Jul 2000 15:25:21 -0500 Message-ID: <396E2644.3780AB71@lucent.com> Date: Thu, 13 Jul 2000 15:27:48 -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 Subject: Re: [SPIRITS] Internet draft References: <000601bfeceb$82f18800$e4d61cd4@swipnet.se> Content-Type: multipart/mixed; boundary="------------3FBCE277BFFA4A768FCAA628" 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. --------------3FBCE277BFFA4A768FCAA628 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jörgen, I think you are right here. This I-D is just a bit early for the group. I like it though! At our meetings we are not supposed to talk about I-D's but SPIRITS issues. It would be interesting to hear in Pittsburgh how and which SPIRITS requirements led you to the protocol selection. If WG decides that these are valid requirements we would have to add them to the Requirements Document. Regards, Alec P.S. Just a procedural note: It was really unnecessary to attach you I-D to the list message. Publishing an I-D at internet-drafts@ietf.org should work just fine. However, I understand that you did that to allow WG to see your I-D faster. Jörgen Björkner wrote: > Hi, > > Here is a draft showing our ideas of how it is possible to realize a SPIRITS > solution. Note that it might go a few steps in advance, since a forma > protocol decision has not been made yet, but I think it reflects how some of > the pre-spirits implementations were built. > > I have submitted it to internet-drafts@ietf.org, but it might take a while > until it is available. > > I think it was not allowed to have attachments to this list, so it I paste > it into the mail below. > > Thanks > /Jörgen > --------------3FBCE277BFFA4A768FCAA628 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 --------------3FBCE277BFFA4A768FCAA628-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Jul 17 17:10: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 RAA09620 for ; Mon, 17 Jul 2000 17:10: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 CA4F5443A1; Mon, 17 Jul 2000 17:10:03 -0400 (EDT) Delivered-To: spirits@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 1711444378 for ; Mon, 17 Jul 2000 17:10:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon Jul 17 17:08:49 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7BAED4435D; Mon, 17 Jul 2000 16:55:40 -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 2F69644347 for ; Mon, 17 Jul 2000 16:55:40 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA29648; Mon, 17 Jul 2000 15:55:37 -0500 Cc: Steve Bellovin Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA29638; Mon, 17 Jul 2000 15:55:36 -0500 Message-ID: <3973735C.948A5FA9@lucent.com> Date: Mon, 17 Jul 2000 15:58:04 -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 list Original-CC: Steve Bellovin Content-Type: multipart/mixed; boundary="------------B4C332823EFEDE1620287B00" Subject: [SPIRITS] Proposed SPIRITS meeting Agenda for discussion 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. --------------B4C332823EFEDE1620287B00 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Good Spirited listmates, Both Steve and I expect this meeting to focus on the SPIRITS Protocol Requirements and SPIRITS Architecture. Please take a look at our proposed agenda for the Pittsburgh meeting: Date: MONDAY, July 31, 2000 Time: 09:00-11:30a.m. 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. IN and PINT related SPIRITS Requirements - Igor Faynberg - 20 minutes; 5. SPIRITS Requirements leading to the Protocol selection - Jörgen Björkner - 20 minutes; 7. Discussion on the proposed SPIRITS Architecture - Lev Slutsman - 25 minutes; 8. Wrap-up - 5 minutes. Regards, Steve and Alec --------------B4C332823EFEDE1620287B00 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 --------------B4C332823EFEDE1620287B00-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jul 18 15:36:06 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 PAA07497 for ; Tue, 18 Jul 2000 15:36:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 20C5D443AC; Tue, 18 Jul 2000 15: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 393624435F for ; Tue, 18 Jul 2000 15:36:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jul 18 15:34:39 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C6FE14435D; Tue, 18 Jul 2000 15:21:29 -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 7669E44347 for ; Tue, 18 Jul 2000 15:21:29 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA10768; Tue, 18 Jul 2000 14:21:26 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA10763; Tue, 18 Jul 2000 14:21:25 -0500 Message-ID: <3974AECA.166723DB@lucent.com> Date: Tue, 18 Jul 2000 14:23:54 -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 list Content-Type: multipart/mixed; boundary="------------E1663F664765EFBBCE37F07C" Subject: [SPIRITS] New I-Ds 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. --------------E1663F664765EFBBCE37F07C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Group, There are several recent quite interesting I-Ds that just surfaced in the IETF I-D archive. The links to them are listed below in no particular order: SPIRITS Architecture http://www.ietf.org/internet-drafts/draft-slutsman-spirits-architecture-00.txt IN- and PINT-related Requirements for SPIRITS Protocol http://www.ietf.org/internet-drafts/draft-faynberg-spirits-inpintreqs-00.txt A SPIRITS solution based on virtual SIP user agents http://www.ietf.org/internet-drafts/draft-bjorkner-spirits-vsua-00.txt A proposal for the provisioning of Call Completion Internet Busy using PINT and SPIRITS http://www.ietf.org/internet-drafts/draft-buller-spirits-ccib-00.txt I am aware of other I-Ds being submitted prior to the deadline of 7/14 and can only guess that they will surface later. Regards, Alec --------------E1663F664765EFBBCE37F07C 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 --------------E1663F664765EFBBCE37F07C-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jul 18 15:56:06 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 PAA16443 for ; Tue, 18 Jul 2000 15:56:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AAE25443B7; Tue, 18 Jul 2000 15:56: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 86AD74437E for ; Tue, 18 Jul 2000 15:56:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jul 18 15:55:01 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7C0AD4435D; Tue, 18 Jul 2000 15:41:51 -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 4C92344347 for ; Tue, 18 Jul 2000 15:41:51 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA10862; Tue, 18 Jul 2000 15:41:49 -0400 Message-ID: <3974B2FC.7E52AB5A@lucent.com> Date: Tue, 18 Jul 2000 15:41:48 -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: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] New I-Ds References: <3974AECA.166723DB@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Alec, You missed the revised pre-SPIRITS implementation draft at http://www.ietf.org/internet-drafts/draft-ietf-spirits-implementations-01.txt. Hui-Lan Alec Brusilovsky wrote: > > Group, > > There are several recent quite interesting I-Ds that just surfaced in > the IETF I-D archive. The links to them are listed below in no > particular order: > > SPIRITS Architecture > http://www.ietf.org/internet-drafts/draft-slutsman-spirits-architecture-00.txt > > IN- and PINT-related Requirements for SPIRITS Protocol > http://www.ietf.org/internet-drafts/draft-faynberg-spirits-inpintreqs-00.txt > > A SPIRITS solution based on virtual SIP user agents > http://www.ietf.org/internet-drafts/draft-bjorkner-spirits-vsua-00.txt > > A proposal for the provisioning of Call Completion Internet Busy using > PINT and SPIRITS > http://www.ietf.org/internet-drafts/draft-buller-spirits-ccib-00.txt > > I am aware of other I-Ds being submitted prior to the deadline of 7/14 > and can only guess that they will surface later. > > Regards, > Alec > > ------------------------------------------------------------------------ > Name: abrusilovsky.vcf > abrusilovsky.vcf Type: VCard (text/x-vcard) > Encoding: 7bit > Description: Card for Alec Brusilovsky _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jul 18 16:04: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 QAA20659 for ; Tue, 18 Jul 2000 16:04:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3D18443AD; Tue, 18 Jul 2000 16:04:05 -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 7422E4437E for ; Tue, 18 Jul 2000 16:04:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jul 18 16:02:56 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 0C30E4435F; Tue, 18 Jul 2000 15:49:47 -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 B388044347 for ; Tue, 18 Jul 2000 15:49:46 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21021; Tue, 18 Jul 2000 14:49:43 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA21018; Tue, 18 Jul 2000 14:49:42 -0500 Message-ID: <3974B56B.59A16D54@lucent.com> Date: Tue, 18 Jul 2000 14:52:11 -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 Subject: Re: [SPIRITS] New I-Ds References: <3974AECA.166723DB@lucent.com> Content-Type: multipart/mixed; boundary="------------A37B913782DFAFB184DB5C26" 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. --------------A37B913782DFAFB184DB5C26 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Another one just surfaced: Pre-Spirits Implementations of PSTN-initiated Services http://www.ietf.org/internet-drafts/draft-ietf-spirits-implementations-01.txt -Alec Alec Brusilovsky wrote: > Group, > > There are several recent quite interesting I-Ds that just surfaced in > the IETF I-D archive. The links to them are listed below in no > particular order: > > SPIRITS Architecture > http://www.ietf.org/internet-drafts/draft-slutsman-spirits-architecture-00.txt > > IN- and PINT-related Requirements for SPIRITS Protocol > http://www.ietf.org/internet-drafts/draft-faynberg-spirits-inpintreqs-00.txt > > A SPIRITS solution based on virtual SIP user agents > http://www.ietf.org/internet-drafts/draft-bjorkner-spirits-vsua-00.txt > > A proposal for the provisioning of Call Completion Internet Busy using > PINT and SPIRITS > http://www.ietf.org/internet-drafts/draft-buller-spirits-ccib-00.txt > > I am aware of other I-Ds being submitted prior to the deadline of 7/14 > and can only guess that they will surface later. > > Regards, > Alec --------------A37B913782DFAFB184DB5C26 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 --------------A37B913782DFAFB184DB5C26-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Jul 18 16:22:05 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 QAA29106 for ; Tue, 18 Jul 2000 16:22:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A35CF4435E; Tue, 18 Jul 2000 16:22: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 A3EF344336 for ; Tue, 18 Jul 2000 16:22:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jul 18 16:20:28 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 08CB74435D; Tue, 18 Jul 2000 16:07:19 -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 B2D0444347 for ; Tue, 18 Jul 2000 16:07:18 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA26512; Tue, 18 Jul 2000 15:07:15 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA26509; Tue, 18 Jul 2000 15:07:14 -0500 Message-ID: <3974B987.F9EC42B3@lucent.com> Date: Tue, 18 Jul 2000 15:09:43 -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 Subject: Re: [SPIRITS] New I-Ds References: <3974AECA.166723DB@lucent.com> <3974B2FC.7E52AB5A@lucent.com> Content-Type: multipart/mixed; boundary="------------E410FAD13F4F0FD786E53852" 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. --------------E410FAD13F4F0FD786E53852 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hui-Lan, My sincerest apologies! No harm intended. Thanks for the correction. -Alec Hui-Lan Lu wrote: > Alec, > > You missed the revised pre-SPIRITS implementation draft at > http://www.ietf.org/internet-drafts/draft-ietf-spirits-implementations-01.txt. > > Hui-Lan > > Alec Brusilovsky wrote: > > > > Group, > > > > There are several recent quite interesting I-Ds that just surfaced in > > the IETF I-D archive. The links to them are listed below in no > > particular order: > > > > SPIRITS Architecture > > http://www.ietf.org/internet-drafts/draft-slutsman-spirits-architecture-00.txt > > > > IN- and PINT-related Requirements for SPIRITS Protocol > > http://www.ietf.org/internet-drafts/draft-faynberg-spirits-inpintreqs-00.txt > > > > A SPIRITS solution based on virtual SIP user agents > > http://www.ietf.org/internet-drafts/draft-bjorkner-spirits-vsua-00.txt > > > > A proposal for the provisioning of Call Completion Internet Busy using > > PINT and SPIRITS > > http://www.ietf.org/internet-drafts/draft-buller-spirits-ccib-00.txt > > > > I am aware of other I-Ds being submitted prior to the deadline of 7/14 > > and can only guess that they will surface later. > > > > Regards, > > Alec > > > > ------------------------------------------------------------------------ > > Name: abrusilovsky.vcf > > abrusilovsky.vcf Type: VCard (text/x-vcard) > > Encoding: 7bit > > Description: Card for Alec Brusilovsky > > _______________________________________________ > SPIRITS mailing list > SPIRITS@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/spirits --------------E410FAD13F4F0FD786E53852 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 --------------E410FAD13F4F0FD786E53852-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 19 02:29:42 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 CAA20291 for ; Wed, 19 Jul 2000 02:29:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 165334433B; Wed, 19 Jul 2000 02:29:40 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by lists.bell-labs.com (Postfix) with ESMTP id D187F44336 for ; Wed, 19 Jul 2000 02:29:17 -0400 (EDT) Received: from inser.loniis.spb.su (inser.loniis.spb.su [195.201.37.61]) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id e6J6TBr17264 for ; Wed, 19 Jul 2000 10:29:11 +0400 (MSD) Received: from marat (los.four.loniis.ru [195.201.37.179]) by inser.loniis.spb.su (8.9.3/8.9.3) with SMTP id KAA20582 for ; Wed, 19 Jul 2000 10:29:06 +0400 (MSD) Message-ID: <00aa01bff14b$451616e0$026fa8c0@nio3.loniis.ru> From: "Marat Nourmiev" To: References: <3974AECA.166723DB@lucent.com> Subject: Re: [SPIRITS] New I-Ds Date: Wed, 19 Jul 2000 10:33:31 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 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 Hi all, My apologize for meddling. Could anyone explain me how related SPIRITS's I-Ds with each other? Is *draft-slutsman-spirits-architecture-00* root of SPIRITS development? Is *draft-ietf-spirits-protocol-00* the protocol baseline text? If I am right, why the Figure 1 of its is incompatible? Regards, Marat Nourmiev ----- Original Message ----- From: Alec Brusilovsky To: SPIRITS list Sent: Tuesday, July 18, 2000 11:23 PM Subject: [SPIRITS] New I-Ds > Group, > > There are several recent quite interesting I-Ds that just surfaced in > the IETF I-D archive. The links to them are listed below in no > particular order: > > SPIRITS Architecture > http://www.ietf.org/internet-drafts/draft-slutsman-spirits-architecture-00.t xt > > IN- and PINT-related Requirements for SPIRITS Protocol > http://www.ietf.org/internet-drafts/draft-faynberg-spirits-inpintreqs-00.txt > > A SPIRITS solution based on virtual SIP user agents > http://www.ietf.org/internet-drafts/draft-bjorkner-spirits-vsua-00.txt > > A proposal for the provisioning of Call Completion Internet Busy using > PINT and SPIRITS > http://www.ietf.org/internet-drafts/draft-buller-spirits-ccib-00.txt > > I am aware of other I-Ds being submitted prior to the deadline of 7/14 > and can only guess that they will surface later. > > Regards, > Alec > _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 19 08:55:44 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 IAA18238 for ; Wed, 19 Jul 2000 08:55:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7B4544341; Wed, 19 Jul 2000 08:55:43 -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 2DCD644336 for ; Wed, 19 Jul 2000 08:55:41 -0400 (EDT) To: spirits@lists.bell-labs.com From: jgato@airtel.es Date: Wed, 19 Jul 2000 14:55:06 +0200 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Version 5.0.2c (Esp.)|8 febrero del 2000) at 07/19/2000 02:56:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Subject: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Protocol 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 IAA18238 After reading the IN- and PINT-related Requirements for SPIRITS Protocol, I have the following comments/questions. In section 4 "IN Requirements", page 3, item 3, it is suggested to match each event with a separate message that corresponds to it. I am not against this proposal, but I do not understand why this is better than having one message for all events. This looks like, in INAP CS2, the choice of sending DP specific operations versus an EventReportBCSM with information about the detected event (ITU-T accepts both, while ETSI only the latter). Can you help me to understand it?. 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. b) Pass parameters associated to the EDP. For example a no answer timer can be passed in to EDP o_No_Answer. For example a "C : SUBSCRIBE , , " could work. 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?. Maybe I do not understand properly the I-D ?. 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 ?. I hope my comments are helpful. Best Regards, Jorge Gató Airtel Móvil _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 19 10:14:08 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 KAA17775 for ; Wed, 19 Jul 2000 10:14:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D21D4437D; Wed, 19 Jul 2000 10:14:05 -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 A4EBE44336 for ; Wed, 19 Jul 2000 10:14:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 19 10:13:30 EDT 2000 Received: by lists.bell-labs.com (Postfix) id E532944361; Wed, 19 Jul 2000 09:47: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 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: [SPIRITS] The New Mailing list for SIP/IN Interworking 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 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 _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 19 14:40:06 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 OAA09697 for ; Wed, 19 Jul 2000 14:40:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 161594433F; Wed, 19 Jul 2000 14:40:05 -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 C14394433B for ; Wed, 19 Jul 2000 14:40:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 19 14:39:01 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3FF104435D; Wed, 19 Jul 2000 14:25:52 -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 12A9244347 for ; Wed, 19 Jul 2000 14:25:52 -0400 (EDT) Received: from lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA06652; Wed, 19 Jul 2000 14:25:51 -0400 Message-ID: <3975F2AF.8A4F85B9@lucent.com> Date: Wed, 19 Jul 2000 14:25:51 -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: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] New I-Ds References: <3974AECA.166723DB@lucent.com> <00aa01bff14b$451616e0$026fa8c0@nio3.loniis.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Marat Nourmiev wrote: > My apologize for meddling. > Could anyone explain me how related SPIRITS's I-Ds with each other? > Is *draft-slutsman-spirits-architecture-00* root of SPIRITS development? > Is *draft-ietf-spirits-protocol-00* the protocol baseline text? > If I am right, why the Figure 1 of its is incompatible? I believe requirements (such as described in draft-faynberg-spirits-inpintreqs-00.txt) will drive the development of the SPIRITS architecture and protocol. draft-slutsman-spirits-architecture-00 is the first cut of the architecture. After we agree on the requirements and architecture, the protocol should emerge. Your observation about the discrepancy is absolutely correct. The reason for it is that draft-ietf-spirits-protocol-00 is an old draft published long before we had our discussions on requirements. Based on our discussions in the near future, we need to either update the draft or incorporate the useful parts into the new protocol document. Hui-Lan Lu _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Jul 19 17:32:08 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 RAA19800 for ; Wed, 19 Jul 2000 17:32: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 CA5A54439D; Wed, 19 Jul 2000 17:32:05 -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 A9CB94433B for ; Wed, 19 Jul 2000 17:32:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jul 19 17:31:43 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 281044435D; Wed, 19 Jul 2000 17:18:34 -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 CFB9544347 for ; Wed, 19 Jul 2000 17:18:33 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA14476; Wed, 19 Jul 2000 16:18:31 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA14473; Wed, 19 Jul 2000 16:18:30 -0500 Message-ID: <39761BBB.FEA6701F@lucent.com> Date: Wed, 19 Jul 2000 16:20:59 -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 Subject: Re: [SPIRITS] New I-Ds References: <3974AECA.166723DB@lucent.com> <3974B2FC.7E52AB5A@lucent.com> Content-Type: multipart/mixed; boundary="------------D7E57DA8F841CB3EBEEC4FD3" 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. --------------D7E57DA8F841CB3EBEEC4FD3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here is another interesting one: Dynamic Call Screening Using a WAP Interface http://www.ietf.org/internet-drafts/draft-reid-wapdcs-00.txt I know that there is one submitted by Lawrence Conroy and Jim Buller. It will surface soon. Regards, Alec Hui-Lan Lu wrote: > Alec, > > You missed the revised pre-SPIRITS implementation draft at > http://www.ietf.org/internet-drafts/draft-ietf-spirits-implementations-01.txt. > > Hui-Lan > > Alec Brusilovsky wrote: > > > > Group, > > > > There are several recent quite interesting I-Ds that just surfaced in > > the IETF I-D archive. The links to them are listed below in no > > particular order: > > > > SPIRITS Architecture > > http://www.ietf.org/internet-drafts/draft-slutsman-spirits-architecture-00.txt > > > > IN- and PINT-related Requirements for SPIRITS Protocol > > http://www.ietf.org/internet-drafts/draft-faynberg-spirits-inpintreqs-00.txt > > > > A SPIRITS solution based on virtual SIP user agents > > http://www.ietf.org/internet-drafts/draft-bjorkner-spirits-vsua-00.txt > > > > A proposal for the provisioning of Call Completion Internet Busy using > > PINT and SPIRITS > > http://www.ietf.org/internet-drafts/draft-buller-spirits-ccib-00.txt > > > > I am aware of other I-Ds being submitted prior to the deadline of 7/14 > > and can only guess that they will surface later. > > > > Regards, > > Alec > > > > ------------------------------------------------------------------------ > > Name: abrusilovsky.vcf > > abrusilovsky.vcf Type: VCard (text/x-vcard) > > Encoding: 7bit > > Description: Card for Alec Brusilovsky > > _______________________________________________ > SPIRITS mailing list > SPIRITS@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/spirits --------------D7E57DA8F841CB3EBEEC4FD3 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 --------------D7E57DA8F841CB3EBEEC4FD3-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Jul 20 06:31:50 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 GAA05147 for ; Thu, 20 Jul 2000 06:31:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BD4B0443BF; Thu, 20 Jul 2000 06:31:47 -0400 (EDT) Delivered-To: spirits@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id D663C4433B for ; Thu, 20 Jul 2000 06:31:44 -0400 (EDT) Received: from cvis01.gpt.co.uk (cvis01.gpt.co.uk) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 20 Jul 2000 11:31:39 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-27) id LAA24976; Thu, 20 Jul 2000 11:31:40 +0100 (BST) From: raymond.forbes@marconi.com Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256922.0039C79E ; Thu, 20 Jul 2000 11:31:06 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT To: spirits@lists.bell-labs.com Message-ID: <80256922.0039C589.00@marconicomms.com> Date: Thu, 20 Jul 2000 11:30:58 +0100 Subject: Re: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Protocol Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=tHZ7LXB0wV4cymuxEsHuTSau9cIgLL5Yqj1kP60bVqoRvUcS8Ct3VB7M" Content-Disposition: inline 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 --0__=tHZ7LXB0wV4cymuxEsHuTSau9cIgLL5Yqj1kP60bVqoRvUcS8Ct3VB7M Content-type: text/plain; charset=us-ascii Content-Disposition: inline Jorge wrote: >In section 4 "IN Requirements", page 3, item 3, it is suggested to match >each event with a separate message that corresponds to it. I am not against >this proposal, but I do not understand why this is better than having one >message for all events. This looks like, in INAP CS2, the choice of sending >DP specific operations versus an EventReportBCSM with information about the >detected event (ITU-T accepts both, while ETSI only the latter). Can you >help me to understand it?. To my understanding the DP Specific Operations work very slowly as the AIN protocol has a very large message set. ETSI support the alternative because it is flexible and extensible without constantly re-inventing the message handling devices. Hence it may be optimised to run faster with cheaper extensions. What is a Semantic Overload of the Protocol Message? I would support that the IETF uses a mechanism closer to the Event Report BCSM (generic Event Notification) otherwise the SPIRITS Proxy and the SPIRITS Server message handler will be very complex. Ray Forbes jgato@airtel.es on 19/07/2000 13:55:06 Please respond to spirits@lists.bell-labs.com To: spirits@lists.bell-labs.com cc: (bcc: Raymond Forbes/MAIN/MC1) Subject: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Protocol --0__=tHZ7LXB0wV4cymuxEsHuTSau9cIgLL5Yqj1kP60bVqoRvUcS8Ct3VB7M Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable After reading the IN- and PINT-related Requirements for SPIRITS Protoco= l, I have the following comments/questions. In section 4 "IN Requirements", page 3, item 3, it is suggested to matc= h each event with a separate message that corresponds to it. I am not aga= inst this proposal, but I do not understand why this is better than having o= ne message for all events. This looks like, in INAP CS2, the choice of sen= ding DP specific operations versus an EventReportBCSM with information about= the detected event (ITU-T accepts both, while ETSI only the latter). Can yo= u help me to understand it?. 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 I= N environment. I understand that both methods to arm events can be applic= able to SPIRITS services. b) Pass parameters associated to the EDP. For example a no answer timer= can be passed in to EDP o_No_Answer. For example a "C : SUBSCRIBE , , " cou= ld work. Besides, I miss more protocol requirements between the SPIRITS client a= nd proxy. There is nothing about the signalling flow for the SPIRITS servi= ce (only the event notification and registration parts are covered). For example, how will the SPIRITS proxy send the SPIRITS server disposition= s about an incoming call to the SPIRITS client (so it is sent later to th= e PSTN invoking network)?. I understand that these requirements can be covered by existing protocols (e.g. SIP), but should not they be specif= ied as a requirement?. Maybe I do not understand properly the I-D ?. 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 Patter= n" being part of TerminationAttemptAuthorized nor "DestinationRoutingAddre= ss" (while many parameters are missing). Can you double check ?. I hope my comments are helpful. Best Regards, Jorge Gat=F3 Airtel M=F3vil _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits = --0__=tHZ7LXB0wV4cymuxEsHuTSau9cIgLL5Yqj1kP60bVqoRvUcS8Ct3VB7M-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jul 21 11:12:12 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 LAA21136 for ; Fri, 21 Jul 2000 11:12:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E865F443DB; Fri, 21 Jul 2000 11:12: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 A183C443CC for ; Fri, 21 Jul 2000 11:12:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jul 21 11:10:04 EDT 2000 Received: by lists.bell-labs.com (Postfix) id C2BF24435F; Fri, 21 Jul 2000 10:56:54 -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 6A0CB44347 for ; Fri, 21 Jul 2000 10:56:54 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA07101; Fri, 21 Jul 2000 09:56:51 -0500 Cc: SPIRITS list , Steve Bellovin Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA07090; Fri, 21 Jul 2000 09:56:49 -0500 Message-ID: <39786547.302AA2EB@lucent.com> Date: Fri, 21 Jul 2000 09:59:20 -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: "agenda@ietf.org" Original-CC: SPIRITS list , Steve Bellovin Content-Type: multipart/mixed; boundary="------------4FFAF7FAA4475CA867F8B264" Subject: [SPIRITS] SPIRITS Agenda for the Pittsburgh meeting 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. --------------4FFAF7FAA4475CA867F8B264 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: MONDAY, July 31, 2000 Time: 09:00-11:30a.m. 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. Regards, Steve Bellovin, Alec Brusilovsky --------------4FFAF7FAA4475CA867F8B264 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 --------------4FFAF7FAA4475CA867F8B264-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jul 21 18:26:05 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 SAA29748 for ; Fri, 21 Jul 2000 18:26:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71DE5443EA; Fri, 21 Jul 2000 18:26: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 E89D444337 for ; Fri, 21 Jul 2000 18:26:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jul 21 18:24:39 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 6BE3E4435F; Fri, 21 Jul 2000 18:11:30 -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 38CF644347 for ; Fri, 21 Jul 2000 18:11:30 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id SAA21253; Fri, 21 Jul 2000 18:11:29 -0400 Message-ID: <3978CA91.90221426@bell-labs.com> Date: Fri, 21 Jul 2000 18:11:29 -0400 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [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 SPIRITSProtocol References: <80256922.0039C589.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 raymond.forbes@marconi.com wrote: > ... > To my understanding the DP Specific Operations work very slowly as the AIN > protocol has a very large message set. > > ETSI support the alternative because it is flexible and extensible without > constantly re-inventing the message handling devices. Hence it may be optimised > to run faster with cheaper extensions. Oh no! If we discuss this any further, we will restart the 10 year old "US vs. Europe" struggle in ITU-T. I am sorry I (unintentionally) triggered it, so to fix the situatio I am not commenting. (In ITU-T I would have been compelled to...) > > What is a Semantic Overload of the Protocol Message? It is a situation in which a syntactic element (a name of a parameter or a message) can have different values (belonging to different domains) depending on the context. For example, a parameter called "spirits" could in one context have a value from a set {beer, wine, vodka, gin}, and--in another context--a value from a set {gremlin, ghost, poltergeist, spook}. As for the message as the whole, overload shows its spooky head when it can have different sets of parameters, again depending on the context. >I would support that the > IETF uses a mechanism closer to the Event Report BCSM (generic Event > Notification) otherwise the SPIRITS Proxy and the SPIRITS Server message handler > will be very complex. I fully agree with Ray. I know my tongue will be cut out by the esteemed chairmen for talking about SIP prematurely, but I think that the SIP/PINT mechanism (possibly augmented) for S...BSCRIBE/NOTIFY is what ought to be used for dynamic setting/notification of DPs, and INVITE for SPIRITS invocation on triggers. Igor _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jul 21 19:38:06 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 TAA26198 for ; Fri, 21 Jul 2000 19:38:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 48D184437F; Fri, 21 Jul 2000 19:38: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 B671544337 for ; Fri, 21 Jul 2000 19:38:01 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jul 21 19:37:05 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 5DA924435F; Fri, 21 Jul 2000 19:23:56 -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 2CDCF44347 for ; Fri, 21 Jul 2000 19:23:56 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id TAA24900; Fri, 21 Jul 2000 19:23:55 -0400 Message-ID: <3978DB8B.8E7074A8@bell-labs.com> Date: Fri, 21 Jul 2000 19:23:55 -0400 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [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 Protocol References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 jgato@airtel.es wrote: > > After reading the IN- and PINT-related Requirements for SPIRITS Protocol, I > have the following comments/questions. > > In section 4 "IN Requirements", page 3, item 3, it is suggested to match > each event with a separate message that corresponds to it. I am not against > this proposal, but I do not understand why this is better than having one > message for all events. This looks like, in INAP CS2, the choice of sending > DP specific operations versus an EventReportBCSM with information about the > detected event (ITU-T accepts both, while ETSI only the latter). Can you > help me to understand it?. A good question and the right observation. Ray just responded to that, and I agree with Jorge (and agreed with Ray) on having one message, as far as the transport protocol is concerned. My idea was to ensure that we pick the ITU standard parameters but avoild--by all means--choosing application context options. It is obvious that the statement I wrote in the requirements caused confusion and it will need to be rewritten. > 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. > b) Pass parameters associated to the EDP. For example a no answer timer can > be passed in to EDP o_No_Answer. > > For example a "C : SUBSCRIBE , , " could > work. Yes! > > 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. > Maybe I do not understand properly the I-D ?. You do, and perfectly so! Just more work needs to be done, and your help is sought. > > 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. > > I hope my comments are helpful. Very helpful (and they demonstrate your top-notch expertise on the subject!). I hope you are coming to the next IETF meeting so I can shake your hand in Pittsburgh. On behalf of the authors' team, I am inviting you to co-author the future version of this I-D. With many thanks, Igor _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Jul 28 10:56:14 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 KAA07736 for ; Fri, 28 Jul 2000 10:56:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 562E844337; Fri, 28 Jul 2000 10:56:10 -0400 (EDT) Delivered-To: spirits@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 E873244336 for ; Fri, 28 Jul 2000 10:56:07 -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:53:37 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Fri, 28 Jul 2000 15:55:53 +0100 To: spirits@lists.bell-labs.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [SPIRITS] Apologies for filling your email... 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 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 SPIRITS draft: ------------------------------------------------------------ SPIRITS Working Group L. Conroy INTERNET-DRAFT Siemens Roke Manor Research Category: Informational J. Buller Expires: January 2001 Unisphere Solutions A list of possible SPIRITS 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 has been 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. It has been requested that mapping to any specific protocol is not undertaken at this juncture. As such, only 'possible' functionality is identified and no mapping to existing protocol methods is given. This document is only intended to provide a basis for discussion and would be expected to form one aspect of the requirements for SPIRITS. As such the terminology used is deliberately and (we hope) suitably ambiguous. Conroy, Buller [Page 1] July, 2000 Contents of the rest of this document are as follows: Section 1:Introduction......................................... 2 Section 2:Classification of actions............................ 3 Section 3:SPIRITS functions.................................... 3 Section 4:Security............................................. 6 Section 5:Summary.............................................. 7 Section 6:References and Glossary.............................. 8 Section 7:Authors' addresses................................... 8 1. Introduction Requirements for an application-specific transport protocol can be captured from three main aspects. These are: * The architecture in which it will operate, * The behaviour expected of the communicating entities and so the pattern of interaction they have, * The information exchanged that is germane to (or qualifies) behaviour engendered by the communication This last aspect can be re-phrased as * The information that is available to the initiating entity that can be passed to the executive or recipient entity Summarising these points as questions: - who communicates? - what are they to do? - what do they need to be told in order to do it? or - what information is available at the sender to tell the recipient? The architectural drafts submitted for the SPIRITS work have so far concentrated on the first question and, in its second form, the last question. Rather than focus on the sender of requests, this note considers the kind of behaviours that the recipient of the request might be asked to perform. Both approaches can be combined to qualify the requirements that the protocol will need to cover; both the state available at the sender AND the behaviours expected of the recipient will have to be taken into account. From the charter (and the ICW service descriptions), the architecture is one in which a PSTN-based system requests actions to be carried out by an Internet-based entity. The PSTN-based system is further qualified as one that maintains call state, and can carry out some internal actions on a transition in this call state. Conroy, Buller [Page 2] July, 2000 The result of these internal actions is that a request for service is constructed and sent to the Internet entity, and that this entity will inform the requestor of either the result of this action, or (at least) that this request has been received and is to be processed. In other drafts, the information available in the PSTN at a given call state is being considered. For example, this could be the data available to an SCF on receiving a DP message from an SSF. In this case, if a request for action in the Internet were to be generated as a result of the SCF receiving the DP message, then there is a limit to the information that could in turn be used to generate the request. This gives a bound for the actions that might be expected of the Internet entity; it reflects the statement that, if you can't tell it how to do something because you don't have the information, then the recipient of a request can't be expected to do it. This note, however, lists the kind of "things that I want you to do". There is also a companion note that lists the kind of things that could be done in the PINT domain. 2. Classification of actions The functions that might be performed by a SPIRITS server in response to request from a PSTN entity are classified in the next section into five sets. This is only an initial view, and is put as a spur to discussion only. The sets are: * Server/Service Registration * Request/Service Processing * VoIP Call Leg Manipulation * SPIRITS Service Monitoring * Special Resource Functions 3. SPIRITS functions 3.1. Server and Service Registration 1) Registrations/ Deregistrations of an Internet entity to the PSTN entity (getting trusted entities 'known' to the PSTN entity). This registration asserts that the registrant is an entity in the SPIRITS architecture. It is most likely to be used to identity a SPIRITS server (i.e. it states that SPIRITS requests may be sent to this entity). 2) Registration of available services in the Internet domain. This registration asserts that this function can be carried out. In practice, the ability to execute this function will be registered by some entity. It seems sensible for the Registrar to assume that the entity making this registration can execute the function, so this registration serves a dual purpose; both to register this function as one that can be performed, AND to register the entity as one that can perform it. Conroy, Buller [Page 3] July, 2000 3.2 Request/Service Processing 3) PSTN requests service handling by entity in Internet domain. This is a request for an action to be performed - "please do ". There are several "flavours" of what happens in response: 4) Service Handling terminated by entity in Internet domain and handed back to entity in PSTN domain for resumption. Internet domain Service handler takes no further interest in service. This variant states "please do as part of my processing". This implication is that the SPIRITS server is carrying out a sub-function and can forget about it afterwards. 5) Service handling passed back to entity in PSTN domain. However, an interest (perhaps implemented as some kind of monitoring function) is maintained by service handler in the Internet domain relating to 'this' instance of service. This differs from the previous function in that the SPIRITS server is informed on the disposition of the PSTN action of which it's processing is a part. This could be used, for example, to allow post-service synchronisation of state between the Internet and the PSTN. 3.3. VoIP Call leg Manipulation Whilst the PINT services can result in a PSTN-based service call, it seems at least possible that SPIRITS services might result in a pure "VoIP" call. This might be executed "behind" the SPIRITS server using, for example, SIP third-party call control actions. The functions described here, however, are the *service requests* to a SPIRITS server, not the way in which that service is executed. 6) Entity in the PSTN domain requests an initial VoIP call This is a request for a VoIP call to be placed between two parties on the Internet. It is, in effect, a "macro-function" in that it could be constructed from two of these subsequent functions. It is likely to be widely used, however, so it may be convenient to consider it as a single command (i.e. one that can be carried out as a result of a single request). 7) Entity in the PSTN domain requests a VoIP call leg This request asks that a VoIP call leg be extended to an entity in the Internet. An open question for the following functions is how call legs are identified. If the call leg has been created in response to an earlier SPIRITS service request, then the identity of the leg to be removed may be able to use a reference to that earlier service request. The detail of the way in which the call leg would be identified is for further discussion, as this service may operate "in the context" of an earlier service. Conroy, Buller [Page 4] July, 2000 It is unclear whether or not the "call control" call leg identity will be known to the PSTN entity that made the earlier request, and so whether or not this can be used somehow to refer to the leg(s) in question. 8) Entity in the PSTN domain requests deletion of a VoIP call leg This request asks that a previously created call leg that exists to an entity in the Internet be removed. 9) Entity in the PSTN domains requests a connection of 2 or more VoIP call legs This requests that two or more call legs that have been previously created should be joined to allow bi-directional media exchange. 10) Entity in the PSTN domain requests a transfer of a VoIP call leg This request asks that the existing association between a call leg and another be dissolved, and that a new association with a different call leg be created. 11) Entity in PSTN domain requests a Hold/Resume for VoIP call leg There are two request types here. In the first, this request asks that a call leg that was in an existing association with another be suspended. In the second, it asks that the association with another call leg that was suspended be reinstated. 3.4. SPIRITS Service Monitoring These functions are the converse of the PINT Subscribe/Notify/Unsubscribe mechanism. 12) Event Notification requests sent from PSTN domain to Internet domain. This is the converse of the PINT Subscribe request. It asks that a monitoring session be instated so that the status of a SPIRITS service (or events within that service) be reported to the PSTN entity. 13) Event Notification responses sent from Internet domain to PSTN domain. This is the converse of the PINT Notify message. It reports on the status or events within a prior SPIRITS service, for which a monitoring relationship with the PSTN entity exists. 14) Event Notification session termination This is the converse of the PINT Unsubscribe request. It is expected that this request is symmetrical, in that it could be sent either from the SPIRITS server to the PSTN entity that has an existing monitoring relationship, or from that PSTN entity to the SPIRITS server to inform it that the monitoring session is no longer required. Conroy, Buller [Page 5] July, 2000 3.5. Special Resource Functions 15) The ability to request an entity in the Internet domain to Output tones or play announcements or messages. This is the Internet equivalent of the I.N. System "play announcement" command to an Intelligent Peripheral. It assumes that there is a reference available at the SPIRITS server to the call leg to be associated with the entity that is to make the announcement; this may be passed from the PSTN entity if it is known from a prior service, or the call leg may be implicit from a reference to a prior service that created the call leg. 16) The ability for an entity in the PSTN domain to collect information from the Internet domain. This is the Internet equivalent of the "collect" command to an Intelligent Peripheral. In the SPIRITS case, however, the application is *much* wider. For example, in the ICW service, the potential terminating user may be asked whether or not they want to accept an incoming call. The way in which they are asked could be via some instant messaging scheme; thus this could cover not only collection of information from an existing call leg within the Internet but also using some other scheme from the potential B party (i.e. where a VoIP call leg has not yet been created). 17) The ability to set service data and user data in the Internet domain from the PSTN domain. This is a fairly wide building block. It can be used, for example, to change the behaviour of Internet entities in response to future events (the equivalent of the "set trigger" action within the PSTN), to change registration/subscribed services state (the equivalent of the PSTN "set service mark" action), to add or change some service related data stored within the Internet. This last might be used, for example, to create an association between an Internet address and a PSTN identifier such as a PSTN address. The kind of detailed action that might be performed is limited by the information available within the PSTN. Refining the scope for this function is for future discussion. 4. Security Security issues are for further discussion. This document is only intended to provide the basis for such discussion. It is expected that any action to be performed be executed only if the recipient of a request is sure that the requestor has a right to make a request, and that the server itself has a right to carry it out. Where "subsequent actions" are to be carried out in the context of an earlier service, then there is a further security implication that the entity requesting this further service has the right to ask for a particular service context to be manipulated (e.g. for a given service call leg to be changed). Conroy, Buller [Page 6] July, 2000 Equally, where monitoring is to be provided, the privacy implications of such actions on the person engaged in a call leg (and any others associated with that call leg) must be considered. 5. Summary This note has described some building blocks for SPIRITS services. The functional building blocks were: * Registrations/ Deregistrations of an Internet entity to the PSTN entity (getting trusted entities 'known' to the PSTN entity) * Registration of available services in the Internet domain * PSTN requests service handling by entity in Internet domain * Service Handling terminated by entity in Internet domain and handed back to entity in PSTN domain for resumption. Internet domain Service handler takes no further interest in service * Service handling passed back to entity in PSTN domain. However, an interest (perhaps implemented as some kind of monitoring function) is maintained by service handler in the Internet domain relating to 'this' instance of service * Entity in the PSTN domain requests an initial VoIP call * Entity in the PSTN domain requests a VoIP call leg * Entity in the PSTN domain requests deletion of a VoIP call leg * Entity in the PSTN domains requests a connection of 2 or more VoIP call legs * Entity in the PSTN domain requests a transfer of a VoIP call leg * Entity in PSTN domain requests a Hold/Resume for VoIP call leg * Event Notification requests sent from PSTN domain to Internet domain * Event Notification responses sent from Internet domain to PSTN domain * Event Notification session termination * The ability to request an entity in the Internet domain to Output tones or play announcements or messages * The ability for an entity in the PSTN domain to collect information from the Internet domain Conroy, Buller [Page 7] July, 2000 * The ability to set service data and user data in the Internet domain from the PSTN domain 6. 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. Glossary SCF - Service Control Function SSF - Service Switching Function DP - Decision Point PSTN - Public Switched Telecommunications Network ICW - Internet Call Waiting 7. 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 8] -- 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 --| _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits