From mailman-owner@lists.bell-labs.com Fri Sep 1 06:16:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07629 for ; Fri, 1 Sep 2000 06:16:27 -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 D02A544649 for ; Fri, 1 Sep 2000 05:03:49 -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: External Test Mailing List Message-Id: <20000901090350.D02A544649@lists.bell-labs.com> Date: Fri, 1 Sep 2000 05:03:50 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, spirits-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for spirits-archive@lists.ietf.org: List Password // URL ---- -------- spirits@lists.bell-labs.com QMKP http://lists.bell-labs.com/mailman/options/spirits/spirits-archive@lists.ietf.org From spirits-admin@lists.bell-labs.com Mon Sep 4 03:49:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00543 for ; Mon, 4 Sep 2000 03:49:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4EE8944373; Mon, 4 Sep 2000 02:49:36 -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 B126944348 for ; Mon, 4 Sep 2000 02:49:33 -0400 (EDT) To: spirits@lists.bell-labs.com From: jgato@airtel.es Date: Mon, 4 Sep 2000 09:48:42 +0200 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Version 5.0.2c (Esp.)|8 febrero del 2000) at 09/04/2000 09:49:32 AM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=2JDEKwEbT0DC2VDykeZZbmN2AS8jFZG3H0RZbYTZ3C3SZhbH2Kj5N2jG" Content-Disposition: inline Subject: [SPIRITS] More on SPIRITS requirements 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__=2JDEKwEbT0DC2VDykeZZbmN2AS8jFZG3H0RZbYTZ3C3SZhbH2Kj5N2jG Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi SPIRITS colleagues, I have been thinking into Igor's questions, and Lawrence's I-D and I h= ave some ideas to share with you. Please, feel free to send your comments and suggestions= . 1) TDPs setting (Igor's question). According to the ITU-T standards, the SMS could be used to set the desi= red TDPs in the SSPs. However, the SMSs from some suppliers are not able to do so. In = some cases an access to the SSP is done via a different nodes (e.g. used for operation and maintenance of the switch). I think we should let this as an implementation option. The requirement is that there exists a way to set the desired TDP in th= e correct SSF(s). This should be preferrably started from the SPIRITS Server (e.g. when the subscribe= r activates ICW subscription). 2) CAMEL DPs in SPIRITS (Igor's suggestion). I am not sure if we should add CAMEL DPs in the SPIRITS requirements. In CAMEL phase 3, several types of "calls" are covered: a) Voice Calls. In this case no new DP is needed since CAMEL DPs are included in CS2. The only special case is the "Not Reachable" case which is mapped as a special= cause in the Busy DP. Since we would receive the Busy DP parameters (if a SPIRITS service h= as subscribed to Busy), we would be able to distinguish a busy from a not reachable situation= . b) USSD. This is not a PSTN call so it does not apply to SPIRITS. c) GPRS. Same comment. d) SMS. Same comment. e) Mobility Management. This could allow a SPIRITS server to be notified in changed of locati= on of a mobile user. However, triggering of these type of services is not based on DPs, but in a subscription mark in the HLR. Adding this to SPIRITS, means: i) Adding a requirement to allow setting subscription marks in the subscriber's HLR. This is equivalent to setting TDPs in the SSP (but in this case M-CSI is se= t in the HLR). ii) Mapping the CAMEL specific operations into events notification = to the SPIRITS client. Since the SCP receives the information about the mobility state, this involves the C interface (is just an extension of the DP notification). I think this is useful for mobile networks and should be added to the= requirements. What do you think ?. The events (not DPs!) which could be notified are: - Location Update in the same VLR service area. - Location Update in another VLR service area. - IMSI attach. - MS initiated IMSI detach. - Network initiated IMSI detach. f) Supplementary Services Notification. This mechanism could allow a SPIRITS server to be aware of a subscrib= er having invoked one of the following supplementary services: Explicit Call Transfer, Call= Deflection, Call Completion on Busy Subscriber or Multi-Party. It is also based on subscriptions marks in the HLR, but in this case = I do not think this information can be used for SPIRITS services. 3) Lawrence Conroy's I-D. I think he has done a good job describing possible actions performed by= a SPIRITS server. He has gone beyond what is needed for the SPIRITS benchmark services, but = this can make SPIRITS be usable for more complicated services. Specifically, in what I have called "Disposition", he has added much mo= re (like leg handling for VoIP calls). The most complicated requirements are the ones related to VoIP calls (t= he rest are either included in our ideas or are easily mapped into CS2 operations). I am not a VoIP expert, but in the protocol in interface C, probably just indicating that the call is to be connected using VoIP would be enough. This would leave complexity in the implementations side. Using multi-leg handling will require a mechanism to identify the calls= legs. This will require a new parameter (leg id) for the SUBSCRIBE message. In the next attachment, I have reviewed the SPIRITS actions proposed by= Lawrence and tried to match them into requirements for SPIRITS protocol (following Igor's I-D= notation). (See attached file: comments_to_draft-conroy-spirits-act-00.txt) Kind Regards and sorry for the long email. Jorge Gat=F3 Airtel M=F3vil Igor Faynberg con fecha 29/07/2000 02:09:20 Asunto: Re: [SPIRITS] IN- and PINT-related Requirements for SPIRITS Protocol Jorge, First of all, I forgot to answer your question: jgato@airtel.es wrote: > > > I understand that the option of accepting the call with VoIP is outsi= de > SPIRITS > and should not be included here, but still we might want to add an op= tion > to the > Accept Call case to indicate VoIP. What do you think ? Yes, we should definitely include that in the requirements. Let us see = if the chairmen allow us. I will ask that question at the meeting. Second, I just put together the viewgraphs on the new issues (with a fu= ll acknowledgement to you), which I am attaching. Between you and me, I still don't understand how you think we could set= TDPs if that is to be done by SMS, but we will need to talk about that. I also wonder if you are interested in adding Wireless DPs (from UMTS o= r Camel), so please let me know. Other than that, I think wea re in full agreemen= t, and your material is very valuable for the Requirements RFC. (Let us do protocol too?) Igor = --0__=2JDEKwEbT0DC2VDykeZZbmN2AS8jFZG3H0RZbYTZ3C3SZhbH2Kj5N2jG Content-type: application/octet-stream; name="=?iso-8859-1?Q?comments=5Fto=5Fdraft-conroy-spirits-act-00.txt?=" Content-Disposition: attachment; filename="=?iso-8859-1?Q?comments=5Fto=5Fdraft-conroy-spirits-act-00.txt?=" Content-Description: Text - character set unknown Content-Transfer-Encoding: base64 PjIuICBDbGFzc2lmaWNhdGlvbiBvZiBhY3Rpb25zDQoNCg0KPjMuIFNQSVJJVFMgZnVuY3Rpb25z DQoNCj4zLjEuICAgIFNlcnZlciBhbmQgU2VydmljZSBSZWdpc3RyYXRpb24NCg0KPiAgIDEpIFJl Z2lzdHJhdGlvbnMvIERlcmVnaXN0cmF0aW9ucyBvZiBhbiBJbnRlcm5ldCBlbnRpdHkNCj4gICAg ICB0byB0aGUgUFNUTiBlbnRpdHkgKGdldHRpbmcgdHJ1c3RlZCBlbnRpdGllcyAna25vd24nDQo+ ICAgICAgdG8gdGhlIFBTVE4gZW50aXR5KS4NCg0KVGhpcyBpcyBlcXVpdmFsZW50IHRvIHRoZSBS RUdJU1RFUiBtZXNzYWdlIGluIG91ciBkcmFmdC4gDQoNCj4gICAyKSBSZWdpc3RyYXRpb24gb2Yg YXZhaWxhYmxlIHNlcnZpY2VzIGluIHRoZSBJbnRlcm5ldCBkb21haW4uDQoNCkkgYW0gbm90IHN1 cmUgdG8gdW5kZXJzdGFuZCB0aGlzLiBXaG8gc3Vic2NyaWJlcyB0byBzZXJ2aWNlcz8uDQpXaGVu IGlzIHRoaXMgZG9uZSAoZHVyaW5nIGEgY2FsbCBvciBub3QpPy4NCg0KDQo+My4yIFJlcXVlc3Qv U2VydmljZSBQcm9jZXNzaW5nDQo+ICAgMykgUFNUTiByZXF1ZXN0cyBzZXJ2aWNlIGhhbmRsaW5n IGJ5IGVudGl0eSBpbiBJbnRlcm5ldCBkb21haW4uDQoNClRoaXMgaXMgZXF1aXZhbGVudCB0byB0 aGUgZXZlbnQgbm90aWZpY2F0aW9uIGluIG91ciBkcmFmdC4NCg0KPiAgIDQpIFNlcnZpY2UgSGFu ZGxpbmcgdGVybWluYXRlZCBieSBlbnRpdHkgaW4gSW50ZXJuZXQgZG9tYWluIGFuZA0KPiAgICAg IGhhbmRlZCBiYWNrIHRvIGVudGl0eSBpbiBQU1ROIGRvbWFpbiBmb3IgcmVzdW1wdGlvbi4gSW50 ZXJuZXQNCj4gICAgICBkb21haW4gU2VydmljZSBoYW5kbGVyIHRha2VzIG5vIGZ1cnRoZXIgaW50 ZXJlc3QgaW4gc2VydmljZS4NCg0KSXQgY2FuIGJlIGNvbnNpZGVyZWQgaW5jbHVkZWQgaW4gdGhl IGxpc3Qgb2YgcG9zc2libGUgZGlzcG9zaXRpb25zDQppbmNsdWRlZCBpbiBvdXIgZHJhZnQuDQoN Cj4gICA1KSBTZXJ2aWNlIGhhbmRsaW5nIHBhc3NlZCBiYWNrIHRvIGVudGl0eSBpbiBQU1ROIGRv bWFpbi4gSG93ZXZlciwNCj4gICAgICBhbiBpbnRlcmVzdCAocGVyaGFwcyBpbXBsZW1lbnRlZCBh cyBzb21lIGtpbmQgb2YgbW9uaXRvcmluZw0KPiAgICAgIGZ1bmN0aW9uKSBpcyBtYWludGFpbmVk IGJ5IHNlcnZpY2UgaGFuZGxlciBpbiB0aGUgSW50ZXJuZXQgZG9tYWluDQo+ICAgICAgcmVsYXRp bmcgdG8gJ3RoaXMnIGluc3RhbmNlIG9mIHNlcnZpY2UuDQoNClRoaXMgaXMgZXF1aXZhbGVudCB0 byBzZW5kaW5nIGEgU1VCU0NSSUJFIGZvciB0aGUgZXZlbnRzIHRvIGJlIA0KbW9uaXRvcmVkIGFu ZCBhIGRpc3Bvc2l0aW9uIGxhdGVyLiBUaGlzIHdheSB0aGUgU1BJUklUUyBzZXJ2aWNlIA0KY29u dGludWVzIG1vbml0b3Jpbmcgb3IgY29udHJvbGxpbmcgdGhlIGNhbGwuDQoNCj4zLjMuICBWb0lQ IENhbGwgbGVnIE1hbmlwdWxhdGlvbg0KDQoNCj4gICA2KSBFbnRpdHkgaW4gdGhlIFBTVE4gZG9t YWluIHJlcXVlc3RzIGFuIGluaXRpYWwgVm9JUCBjYWxsDQoNClRoaXMgaXMgbm90IGluY2x1ZGVk IGluIG91ciBkcmFmdC4gV2Ugd291bGQgbmVlZCBhIG5ldyBtZXNzYWdlIHRvDQppbmRpY2F0ZSB0 aGF0IHN1Y2ggY2FsbCBuZWVkcyB0byBiZSBjcmVhdGVkIChsZWF2aW5nIHRoZSBjb21wbGV4aXR5 DQpvZiBjcmVhdGluZyBzdWNoIGEgY2FsbCB0byBTQ1AgYW5kIFNTUCBsZXZlbCkuDQoNClRoZSBt ZXNzYWdlIGNhbiBiZSBsaWtlOg0KDQpTLT5QOiA8W0FjY2VwdCBhcyBWb0lQIENhbGxdPg0KDQph bmQgd291bGQgYmUgYSBuZXcgY2FsbCBkaXNwb3NpdGlvbi4NCg0KVGhpcyBtZXNzYWdlIGNhbiBi ZSBzZWVuIGFzIGEgY29tYmluYXRpb24gb2YgbWVzc2FnZXMgaW5jbHVkZWQNCmJlbG93Lg0KDQo+ ICAgNykgRW50aXR5IGluIHRoZSBQU1ROIGRvbWFpbiByZXF1ZXN0cyBhIFZvSVAgY2FsbCBsZWcN Cg0KVGhpcyBpcyBhbHNvIG5vdCBpbiBvdXIgZHJhZnQuIFdlIHdvdWxkIG5lZWQgYSBuZXcgbWVz c2FnZSBmb3IgdGhpcy4NClRoZSBtZXNzYWdlIGNhbiBiZSBsaWtlOg0KDQpTLT5QOiA8W0NyZWF0 ZSBWb0lQIENhbGwgbGVnIDxsZWcgaWQ+XT4NCg0KTXkgcHJvcG9zYWwgaXMgdG8gaWRlbnRpZnkg dGhlIGRpZmZlcmVudCBjYWxsIGxlZ3MgY291bGQgYmUgdG8gdXNlIHRoZQ0Kc2FtZSBjcml0ZXJp YSB1c2VkIGluIENTeCBJTiBwcm90b2NvbCAobGVnIDEgaXMgdGhlIGluY29taW5nIGNhbGwsDQph bmQgdGhlIHJlc3QgaGF2ZSBhIG51bWJlciBkZWNpZGVkIGJ5IHRoZSBhcHBsaWNhdGlvbikuDQoN CkRlcGVuZGluZyBvbiB0aGUgc2VsZWN0ZWQgcHJvdG9jb2wsIHRoaXMgY2FuIHJlcXVpcmUgYSBt YXBwaW5nIHRhYmxlDQpiZXR3ZWVuIGludGVybmFsIGlkZW50aWZpY2F0aW9uIG9mIGxlZ3MgYW5k IHRoZSBudW1iZXJpbmcgdXNlZCBieQ0KdGhlIFNQSVJJVFMgcHJvdG9jb2wuIElzIHRoZXJlIGFu eSBvdGhlciBvcHRpb24/Lg0KDQpUaGUgc2VsZWN0ZWQgcHJvdG9jb2wgd291bGQgaGF2ZSB0aGUg YmFzaWMgcmVxdWlyZW1lbnQgdG8gYmUgYWJsZQ0KdG8gY29ycmVsYXRlIG1lc3NhZ2VzIGluIGEg ImRpYWxvZ3VlIi4gVGhpcyByZXF1aXJlbWVudCB0byBjb3JyZWxhdGUgDQptZXNzYWdlcyBpcyBu b3Qgc3BlY2lmaWMgdG8gdGhpcyBjYXNlLCBzaW5jZSBhIERQIG5vdGlmaWNhdGlvbiBuZWVkcyAN CnRvIGJlIGxpbmtlZCB0byB0aGUgU1VCU0NSSUJFIG1lc3NhZ2Ugd2hpY2ggcmVxdWVzdGVkIHN1 Y2ggbm90aWZpY2F0aW9uLg0KDQpUaHVzLCBhZGRpbmcgdGhlIGxlZyBpZCBudW1iZXJpbmcgc2hv dWxkIGJlIGVub3VnaCAodGhlIGRpZmZlcmVudCANCm1lc3NhZ2VzIHJlbGF0ZWQgdG8gb25lIGlu c3RhbmNlIG9mIGEgU1BSSVRJUyBzZXJ2aWNlIHdpbGwgYmUgDQpjb3JyZWxhdGVkKS4NCg0KU2lu Y2UgY3JlYXRpbmcgYSBjYWxsIGxlZyBsaWtlIHRoaXMgZG9lcyBub3QgZmluaXNoIGluIGNvbW11 bmljYXRpb24NCmJldHdlZW4gcGFydGllcywgc3VjaCBtZXNzYWdlIHNob3VsZCBhbHdheXMgYmUg cHJlY2VlZGVkIGJ5IGEgDQpTVUJTQ1JJQkUgZm9yIGV2ZW50cywgc28gdGhhdCB0aGUgU1BJUklU UyBzZXJ2aWNlIGNhbiBiZSBjb21wbGV0ZWQNCmFmdGVyd2FyZHMgKGUuZy4gY29ubmVjdGluZyB0 byBhbm90aGVyIFZvSVAgY2FsbCBsZWcpLg0KDQpBbm90aGVyIGltcGFjdCBjYXVzZWQgaXMgdGhh dCwgc2luY2UgU1BJUklUUyBwcm90b2NvbCB3b3VsZCBuZWVkIHRvDQpoYW5kbGUgbXVsdGktbGVn IGNhbGxzLCB0aGUgU1VCU0NSSUJFIG1lc3NhaGUgd291bGQgbmVlZCB0byBpbmRpY2F0ZQ0KZm9y IHdoaWNoIGNhbGwgbGVnIHRoZSBzdWJzY3JpcHRpb24gb2YgRFAgaXMgcmVxdWVzdGVkLg0KDQpU aGlzIHdvdWxkIGxlYXZlIHRoZSBtZXNzYWdlIGFzIGZvbGxvd3M6DQoNClNVQlNDUklCRSA8RXZl bnQ+LCA8TW9kZT4sIDxQYXJhbWV0ZXJzPiwgPGxlZyBpZD4NCg0Kb3IgbWFraW5nIGxlZyBpZCBw YXJ0IG9mIHRoZSBQYXJhbWV0ZXJzIGZpZWxkLg0KDQo+ICAgOCkgRW50aXR5IGluIHRoZSBQU1RO IGRvbWFpbiByZXF1ZXN0cyBkZWxldGlvbiBvZiBhIFZvSVAgY2FsbCBsZWcNCg0KU2FtZSBhcyBp biA3LCBhIG5ldyBtZXNzYWdlIHdvdWxkIGJlIG5lZWRlZDoNCg0KUy0+UDogPFtEZWxldGUgVm9J UCBDYWxsIGxlZyA8bGVnIGlkPl0+DQoNCj4gICA5KSBFbnRpdHkgaW4gdGhlIFBTVE4gZG9tYWlu cyByZXF1ZXN0cyBhIGNvbm5lY3Rpb24gb2YgMiBvciBtb3JlIFZvSVANCj4gICAgICBjYWxsIGxl Z3MNCg0KU2FtZSBhcyBpbiA3LCBhIG5ldyBtZXNzYWdlIHdvdWxkIGJlIG5lZWRlZDoNCg0KUy0+ UDogPFtDb25uZWN0IFZvSVAgQ2FsbCBsZWdzIDxsZWcgaWQxPiwgPGxlZyBpZDI+XT4NCg0KPiAg MTApIEVudGl0eSBpbiB0aGUgUFNUTiBkb21haW4gcmVxdWVzdHMgYSB0cmFuc2ZlciBvZiBhIFZv SVAgY2FsbCBsZWcNCg0KU2FtZSBhcyBpbiA3LCBhIG5ldyBtZXNzYWdlIHdvdWxkIGJlIG5lZWRl ZDoNCg0KUy0+UDogPFtUcmFuc2ZlciBWb0lQIENhbGwgbGVnIDxsZWcgaWQ+LCA8b2xkIGxlZyBp ZD4sIDxuZXcgbGVnIGlkPl0+DQoNCj4gIDExKSBFbnRpdHkgaW4gUFNUTiBkb21haW4gcmVxdWVz dHMgYSBIb2xkL1Jlc3VtZSBmb3IgVm9JUCBjYWxsIGxlZw0KDQpTYW1lIGFzIGluIDcsIGJ1dCBp biB0aGlzIGNhc2UgdHdvIG5ldyBtZXNzYWdlcyB3b3VsZCBiZSBuZWVkZWQ6DQoNClMtPlA6IDxb SG9sZCBWb0lQIENhbGwgbGVnIDxsZWcgaWQ+XT4NClMtPlA6IDxbUmVzdW1lIFZvSVAgQ2FsbCBs ZWcgPGxlZyBpZD5dPg0KDQo+My40LiAgU1BJUklUUyBTZXJ2aWNlIE1vbml0b3JpbmcNCg0KDQo+ ICAxMikgRXZlbnQgTm90aWZpY2F0aW9uIHJlcXVlc3RzIHNlbnQgZnJvbSBQU1ROIGRvbWFpbiB0 byBJbnRlcm5ldA0KPiAgICAgIGRvbWFpbi4NCg0KRG8gd2UgcmVhbGx5IG5lZWQgdGhpcyBpbiBT UElSSVRTPy4gSSBtYXkgYmUgYSBiaXQgbG9zdCBoZXJlLiBJIGRvIG5vdA0KdW5kZXJzdGFuZCB3 aHkgdGhlIFBTVE4gbWF5IG5lZWQgdG8gZ2V0IGV2ZW50cyBmcm9tIFNQSVJJVFMgc2VydmljZXMu DQpJcyB0aGlzIGEgbWFuYWdlbWVudCB0eXBlIG9mIHJlcXVpcmVtZW50Py4gQ2FuIHRoaXMgaW5m b3JtYXRpb24gYmUNCmFjY2Vzc2VkIGR1cmluZyBhIGNhbGwgKG9yIG9mZi1saW5lKT8uIENhbiB0 aGlzIGluZm9ybWF0aW9uIGJlIA0KcmVxdWVzdGVkIGJ5IGFueW9uZSBmb3IgYW55IFNQSVJJVFMg c2VydmljZSAob3IgYXJlIHRoZXJlIGFjY2Vzcw0KcmVzdHJpY3Rpb25zKT8uIEhvdyBpcyB0aGlz IHJlcG9ydGVkIChQU1ROIGRvZXMgbm90IGFsbG93IG1hbnkNCg0KPiAgMTMpIEV2ZW50IE5vdGlm aWNhdGlvbiByZXNwb25zZXMgc2VudCBmcm9tIEludGVybmV0IGRvbWFpbiB0byBQU1RODQo+ICAg ICAgZG9tYWluLg0KDQpTYW1lIGNvbW1lbnQgdGhhbiBwb2ludCAxMi4NCg0KPiAgMTQpIEV2ZW50 IE5vdGlmaWNhdGlvbiBzZXNzaW9uIHRlcm1pbmF0aW9uDQoNClNhbWUgY29tbWVudCB0aGFuIHBv aW50cyAxMiBhbmQgMTMuDQoNCg0KPjMuNS4gU3BlY2lhbCBSZXNvdXJjZSBGdW5jdGlvbnMNCg0K PiAgMTUpIFRoZSBhYmlsaXR5IHRvIHJlcXVlc3QgYW4gZW50aXR5IGluIHRoZSBJbnRlcm5ldCBk b21haW4gdG8gT3V0cHV0DQo+ICAgICAgdG9uZXMgb3IgcGxheSBhbm5vdW5jZW1lbnRzIG9yIG1l c3NhZ2VzLg0KDQpJIGRvIG5vdCBzZWUgdGhlIG5lZWQgZm9yIHRoaXMgdG9kYXkgKHNpbmNlIHRo ZSBQU1ROIGNhbiBkbyBpdCkuIEkgDQp1bmRlcnN0YW5kIHRoaXMgaXMgYSByZXF1aXJlbWVudCBm b3IgdGhlIGZ1dHVyZS4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgYSBuZXcgbWVzc2FnZSBsaWtlIHRo ZSBmb2xsb3dpbmcgY291bGQgYmUgbmVjZXNzYXJ5Og0KDQpDLT5QOiA8W0FwcGx5IE1lc3NhZ2Ug PHR5cGUgb2YgbWVzc2FnZT4sIDxzcGVjaWZpYyBwYXJhbWV0ZXJzPiwgPGxlZyBpZD5dPg0KDQpX aGVyZSwgZm9yIGV4YW1wbGU6DQoNCi10eXBlIG9mIG1lc3NhZ2UgY2FuIGJlOiB0b25lLCBhbm5v dW5jZW1lbnQgb3IgbWVzc2FnZS4NCi1zcGVjaWZpYyBwYXJhbWV0ZXJzIGRlcGVuZCBvbiB0aGUg dHlwZSBvZiBtZXNzYWdlOg0KDQogIGZvciB0b25lIGNhbiBiZSAidG9uZSBpZCIsICJudW1iZXIg b2YgcmVwZXRpdGlvbnMiIGFuZCAiZHVyYXRpb24iDQogIGZvciBhbm5jLiBjYW4gYmUgImFubmMg aWQiLCAibnVtYmVyIG9mIHJlcGV0aXRpb25zIiBhbmQgImR1cmF0aW9uIg0KICBmb3IgbWVzZy4g Y2FuIGJlICJtZXNzYWdlIGlkIi4NCg0KPiAgMTYpIFRoZSBhYmlsaXR5IGZvciBhbiBlbnRpdHkg aW4gdGhlIFBTVE4gZG9tYWluIHRvIGNvbGxlY3QNCj4gICAgICBpbmZvcm1hdGlvbiBmcm9tIHRo ZSBJbnRlcm5ldCBkb21haW4uDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgZG9uZSBhZnRl ciBhIG1lc3NhZ2UgaXMgYXBwbGllZC4gVGh1cyB0aGUNCm1lc3NhZ2UgY291bGQgYmU6DQoNCkMt PlA6IDxbQ29sbGVjdCBJbmZvcm1hdGlvbiA8bGVnIGlkPiwgPHZhbGlkYXRpb24gcnVsZXM+XT4N Cg0KVGhlIHZhbGlkYXRpb24gcnVsZXMgY291bGQgYmUgdXNlZCB0byB2ZXJpZnkgdGhlIGluZm9y bWF0aW9uIGVudGVyZWQNCmJ5IHRoZSB1c2VyIG1lZXRzIHNvbWUgcmVxdWlyZW1lbnRzLiBGb3Ig dHJhZGl0aW9uYWwgSU4gdGhpbmdzIGxpa2UNCm1pbmltdW0gb3IgbWF4aW11bSBudW1iZXIgb2Yg ZGlnaXRzLCB0byBjb2xsZWN0IG9yIHRpbWVvdXRzIGFyZSANCmNoZWNrZWQuIEZvciBhbiBpbnRl cm5ldCBiYXNlZCBhcHBsaWNhdGlvbiBicm9hZGVyIG1lY2hhbmlzbXMgdG8gDQplbnRlciBpbmZv cm1hdGlvbiAoZS5nLiB0ZXh0IGNhbiBiZSB1c2VkKSBhcmUgYWxsb3dlZCwgdGh1cyByZXF1aXJp bmcNCm1vcmUgZmxleGlibGUgdmFsaWRhdGlvbiBydWxlcy4NCg0KDQo+ICAxNykgVGhlIGFiaWxp dHkgdG8gc2V0IHNlcnZpY2UgZGF0YSBhbmQgdXNlciBkYXRhIGluIHRoZSBJbnRlcm5ldCBkb21h aW4NCj4gICAgICBmcm9tIHRoZSBQU1ROIGRvbWFpbi4NCg0KVGhpcyByZXF1aXJlcyB0aGUgcHJv dG9jb2wgdG8gYWxsb3cgZGF0YSBjaGFuZ2VzIGluIHRoZSBzdWJzY3JpYmVyIA0Kc3BlY2lmaWMg ZGF0YSBvciBzZXJ2aWNlIGRhdGEuDQoNClRodXMgYSBuZXcgbWVzc2FnZSB3b3VsZCBhbHNvIGJl IG5lZWRlZDoNCg0KQy0+UDogWzxTZXQgRGF0YSA8dHlwZSBvZiBkYXRhPiwgPG5ldyBkYXRhPl0N Cg0Kd2hlcmUgdHlwZSBvZiBkYXRhIG5lZWRzIHRvIGluZGljYXRlIGlzIGl0cyBzY29wZSBpcyBm b3IgdGhlIHN1YnNjcmliZXINCm9yIGZvciB0aGUgd2hvbGUgU1BJUklUUyBzZXJ2aWNlLCBzbyB0 aGF0IGJvdGggc2VydmljZSBvciBzdWJzY3JpYmVyIA0Kc3BlY2lmaWMgZGF0YSBjYW4gYmUgYWRk ZWQuDQoNClNpbmNlIHRoaXMgYWN0aW9uIGlzIGRvbmUgd2l0aGluIGEgU1BJUklUUyBzZXJ2aWNl IGludm9jYXRpb24gdGhlDQpzZXJ2aWNlIGlkIGFuZCBzdWJzY3JpYmVyIGlkIG5lZWQgdG8gaGF2 ZSBiZWVuIGFscmVhZHkgaWRlbnRpZmllZC4NCg0KDQoNCg0K --0__=2JDEKwEbT0DC2VDykeZZbmN2AS8jFZG3H0RZbYTZ3C3SZhbH2Kj5N2jG-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Mon Sep 4 23:40:01 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 XAA12038 for ; Mon, 4 Sep 2000 23: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 B49974435C; Mon, 4 Sep 2000 22: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 ABAD54433A for ; Mon, 4 Sep 2000 22:40:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Sep 4 23:39:26 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3DADD44347; Mon, 4 Sep 2000 23:26:16 -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 DDB5844341 for ; Mon, 4 Sep 2000 23:26:15 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA11152; Mon, 4 Sep 2000 22:26:11 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA11103; Mon, 4 Sep 2000 22:26:09 -0500 Message-ID: <39B46887.7C88DA6A@lucent.com> Date: Mon, 04 Sep 2000 22:29:11 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] More on SPIRITS requirements References: Content-Type: multipart/mixed; boundary="------------BB9C221247B97F0A8471A7CC" 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. --------------BB9C221247B97F0A8471A7CC Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Jorge, Igor, Good ideas! please see my comments inline. -Alec jgato@airtel.es wrote: > Hi SPIRITS colleagues, > > I have been thinking into Igor's questions, and Lawrence's I-D and I have > some ideas to > share with you. Please, feel free to send your comments and suggestions . > > 1) TDPs setting (Igor's question). > > According to the ITU-T standards, the SMS could be used to set the desired > TDPs in the > SSPs. However, the SMSs from some suppliers are not able to do so. In some > cases an access > to the SSP is done via a different nodes (e.g. used for operation and > maintenance of the switch). > > I think we should let this as an implementation option. Agree, this would be the most advisable, unless there is a clear need to have this standardized. > > ... > > 2) CAMEL DPs in SPIRITS (Igor's suggestion). > > I am not sure if we should add CAMEL DPs in the SPIRITS requirements. > > In CAMEL phase 3, several types of "calls" are covered: > > a) Voice Calls. In this case no new DP is needed since CAMEL DPs are > included in CS2. The only > special case is the "Not Reachable" case which is mapped as a special > cause in the Busy DP. > Since we would receive the Busy DP parameters (if a SPIRITS service has > subscribed to Busy), > we would be able to distinguish a busy from a not reachable situation . > > b) USSD. This is not a PSTN call so it does not apply to SPIRITS. > > c) GPRS. Same comment. > > d) SMS. Same comment. > > e) Mobility Management. > > This could allow a SPIRITS server to be notified in changed of location > of a mobile user. This is VERY important and can be a building block for a whole slew of SPIRITS services. > However, > triggering of these type of services is not based on DPs, but in a > subscription mark in the HLR. > I would like to start a discussion on this. Can we look at the Subscription Mark in the HLR (IN network element) as "sort of DP"? > Adding this to SPIRITS, means: > > i) Adding a requirement to allow setting subscription marks in the > subscriber's HLR. This is > equivalent to setting TDPs in the SSP (but in this case M-CSI is set in > the HLR). > ii) Mapping the CAMEL specific operations into events notification to > the SPIRITS client. Since > the SCP receives the information about the mobility state, this > involves the C interface (is just > an extension of the DP notification). > > I think this is useful for mobile networks and should be added to the > requirements. What do you > think ?. I am for this assuming that it can pass the "Charter Test". > > > The events (not DPs!) which could be notified are: > > - Location Update in the same VLR service area. > - Location Update in another VLR service area. > - IMSI attach. > - MS initiated IMSI detach. > - Network initiated IMSI detach. > Love this list! > > f) Supplementary Services Notification. > > This mechanism could allow a SPIRITS server to be aware of a subscriber > having invoked one > of the following supplementary services: Explicit Call Transfer, Call > Deflection, Call Completion > on Busy Subscriber or Multi-Party. > > It is also based on subscriptions marks in the HLR, but in this case I do > not think this information > can be used for SPIRITS services. > > 3) Lawrence Conroy's I-D. > > I think he has done a good job describing possible actions performed by a > SPIRITS server. He > has gone beyond what is needed for the SPIRITS benchmark services, but this > can make SPIRITS > be usable for more complicated services. > > Specifically, in what I have called "Disposition", he has added much more > (like leg handling for VoIP > calls). > > The most complicated requirements are the ones related to VoIP calls (the > rest are either included in > our ideas or are easily mapped into CS2 operations). I am not a VoIP > expert, but in the protocol in > interface C, probably just indicating that the call is to be connected > using VoIP would be enough. > This would leave complexity in the implementations side. > > Using multi-leg handling will require a mechanism to identify the calls > legs. This will require a new > parameter (leg id) for the SUBSCRIBE message. > > In the next attachment, I have reviewed the SPIRITS actions proposed by > Lawrence and tried to > match them into requirements for SPIRITS protocol (following Igor's I-D > notation). > > (See attached file: comments_to_draft-conroy-spirits-act-00.txt) > > Kind Regards and sorry for the long email. > > Jorge Gató > Airtel Móvil > > Igor Faynberg con fecha 29/07/2000 02:09:20 > Asunto: Re: [SPIRITS] IN- and PINT-related Requirements for SPIRITS > Protocol > > Jorge, > > First of all, I forgot to answer your question: > > jgato@airtel.es wrote: > > > > > > I understand that the option of accepting the call with VoIP is outside > > SPIRITS > > and should not be included here, but still we might want to add an option > > to the > > Accept Call case to indicate VoIP. What do you think ? > > Yes, we should definitely include that in the requirements. Let us see if > the > chairmen allow us. I will ask that question at the meeting. > > Second, I just put together the viewgraphs on the new issues (with a full > acknowledgement to you), which I am attaching. > > Between you and me, I still don't understand how you think we could set > TDPs if > that is to be done by SMS, but we will need to talk about that. > I also wonder if you are interested in adding Wireless DPs (from UMTS or > Camel), > so please let me know. Other than that, I think wea re in full agreement, > and > your material is very valuable for the Requirements RFC. (Let us do > protocol > too?) > > Igor > > ------------------------------------------------------------------------ > Name: comments to draft-conroy-spirits-act-00.txt > comments to draft-conroy-spirits-act-00.txt Type: Plain Text (text/plain) > Encoding: base64 > Description: Text - character set unknown --------------BB9C221247B97F0A8471A7CC 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 --------------BB9C221247B97F0A8471A7CC-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Sep 5 00:08: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 AAA12298 for ; Tue, 5 Sep 2000 00:08: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 4DF5D4433A; Mon, 4 Sep 2000 23:08: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 86F8E44336 for ; Mon, 4 Sep 2000 23:08:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Sep 5 00:07:13 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 543A844347; Mon, 4 Sep 2000 23:54:04 -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 0669F44341 for ; Mon, 4 Sep 2000 23:54:04 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA14737; Mon, 4 Sep 2000 22:53:59 -0500 Cc: Lawrence Conroy Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA14734; Mon, 4 Sep 2000 22:53:57 -0500 Message-ID: <39B46F0B.411EEFF1@lucent.com> Date: Mon, 04 Sep 2000 22:56:59 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: spirits@lists.bell-labs.com Original-CC: Lawrence Conroy Subject: Re: [SPIRITS] More on SPIRITS requirements References: Content-Type: multipart/mixed; boundary="------------4945411756076D101EDB2891" 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. --------------4945411756076D101EDB2891 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jorge, Igor, There is something else: jgato@airtel.es wrote: > ... > > Specifically, in what I have called "Disposition", he [Lawrence Conroy] has added much more > (like leg handling for VoIP > calls). > ... Please, let us not go again into that area of VOIP. This is NOT what SPIRITS is about! Lawrence is aware of that more than anyone else on this list and stated precisely that in his talk last meeting in Pittsburgh.. Regards, Alec --------------4945411756076D101EDB2891 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 --------------4945411756076D101EDB2891-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Tue Sep 5 15:54: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 PAA12665 for ; Tue, 5 Sep 2000 15:54: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 0E7AE44375; Tue, 5 Sep 2000 14:54: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 457F44436F for ; Tue, 5 Sep 2000 14:54:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Sep 5 15:53:33 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 1B41244370; Tue, 5 Sep 2000 15:40:24 -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 BBD8844341 for ; Tue, 5 Sep 2000 15:40:23 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA11977; Tue, 5 Sep 2000 14:40:18 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA11972; Tue, 5 Sep 2000 14:40:18 -0500 Message-ID: <39B54CD8.32128019@lucent.com> Date: Tue, 05 Sep 2000 14:43:20 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: SPIRITS list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SPIRITS] SPIRITS list moderation policy [Fwd: IESG Statement on WG Moderated Lists (fwd)] 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 Dear listmates, According to the attached 'IESG guidance on the moderation of IETF Working Group Mailing Lists' and with the AD approval I am posting the following SPIRITS mailing list moderation policy: 1. The primary purpose of this Moderation Policy is to prevent obvious spam from being posted. 2. To achieve this, postings from non-members mail accounts will be individually screened. That may result in some delay. 3. Any message with non-ASCII attachment will be rejected. Regards, Alec -------- Original Message -------- Subject: IESG Statement on WG Moderated Lists (fwd) Date: Tue, 5 Sep 2000 09:58:17 -0400 (Eastern Daylight Time) From: Steve Coya To: wgchairs@ietf.org The third of three ---------- Forwarded message ---------- Date: Tue, 29 Aug 2000 08:33:03 -0400 From: Fred Baker To: IETF-Announce: ; Subject: IESG Statement on WG Moderated Lists IESG guidance on the moderation of IETF Working Group Mailing Lists In some cases, it is necessary and appropriate to moderate IETF mailing lists. For example, moderation might be needed to control excessive spam, persistent off-topic postings, persistent personal attacks, etc. on mailing lists. The IESG has devised the following set of guidelines for the moderation of mailing lists. 1) The appropriate AD(s) must approve of a list being moderated. 2) The WG should be kept informed of a mailing list's moderation policy. For example, a message could be posted to the mailing list on a regular basis, or new members could be sent the policy as part of the welcome message when subscribing. 3) Messages should be accepted or rejected in whole; selective editing of messages to remove off-topic content is not permitted. 4) When rejecting a note, a note must be returned to the author with a short explanation. 5) Rejected notes should be saved for a reasonable period of time, so that there is a record in the event a dispute arises. 6) Items 3-5 apply to all manually rejected messages that require some thinking on the part of the moderator. They do not apply to obvious off-topic "make money fast" messages, or messages rejected through generic automated means (i.e., automated spam-filters on mailing list software). Fred Baker Chair, IETF _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Wed Sep 6 17:58: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 RAA23883 for ; Wed, 6 Sep 2000 17:58: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 5B7FF443A5; Wed, 6 Sep 2000 16:58:05 -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 5A9F04439A for ; Wed, 6 Sep 2000 16:58:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Wed Sep 6 17:57:13 EDT 2000 Received: by lists.bell-labs.com (Postfix) id BEB9144370; Wed, 6 Sep 2000 17:44:03 -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 68B4B44341 for ; Wed, 6 Sep 2000 17:44:03 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA21025; Wed, 6 Sep 2000 16:44:00 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA21003; Wed, 6 Sep 2000 16:44:00 -0500 Message-ID: <39B6BB55.AAE10443@lucent.com> Date: Wed, 06 Sep 2000 16:47:01 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: SPIRITS list Content-Type: multipart/mixed; boundary="------------060071C03FE0516B06CC098C" Subject: [SPIRITS] State of the WG 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. --------------060071C03FE0516B06CC098C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Good SPIRITED listmates, The best way to assess the status of the WG is to look how well it is adhering to its Charter and completing its milestones. Let us take a look at the SPIRITS milestones progress: On August 14 the I-D "Pre-Spirits Implementations of PSTN-initiated Services", , our first milestone, was submited for the IESG approval of its publication as an Informational RFC. Congratulations to H. Lu (Editor), I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, L. Robart ! (the names are listed here in the order they appear in the I-D). Currently, Hui-Lan is making editorial changes, incorporating AD's comments, and is preparing the second iteration submission to the IESG. As a result of our Pittsburgh meeting two architectural proposals: Lev Slutsman/Igor Faynberg/Jorge Gato and Jörgen Björkner/Sören Nyckelgård are good candidates for merge. Two parties are working together and will publish the proposed SPIRITS Architecture on this list for review. Being driven by converging SPIRITS Architecture there is a set of SPIRITS Protocol Requirements that is beginning to emerge. Igor Faynberg, Jorge Gato, Jörgen Björkner and Sören Nyckelgård are leading this work. Also, as a result of the Pittsburgh meeting, there are signs that many of the SPIRITS protocol requirements (interoperability with PINT and IN, utilizing existing and proven protocol, etc.) are pointing in the SIP direction. As we said at the meeting, we do not have to agree on SIP at this moment, however, it is a good item for discussion on this list. Kind regards, Steve and Alec P.S. Igor and Jorge have recently started a very interesting discussion on CAMEL DPs in SPIRITS. --------------060071C03FE0516B06CC098C 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 --------------060071C03FE0516B06CC098C-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Thu Sep 7 19:20:20 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 SMTP id TAA29463 for ; Thu, 7 Sep 2000 19:20: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 A6633443E6; Thu, 7 Sep 2000 18:20:21 -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 62517443DD for ; Thu, 7 Sep 2000 18:20:19 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 8 Sep 2000 00:20:15 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-28) id AAA10147; Fri, 8 Sep 2000 00:20:13 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256953.00801D99 ; Fri, 8 Sep 2000 00:19:21 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Jane Humphrey" To: spirits@lists.bell-labs.com Cc: spirits@lists.bell-labs.com Message-ID: <80256953.00801D46.00@marconicomms.com> Date: Thu, 7 Sep 2000 23:53:57 +0100 Subject: Re: [SPIRITS] More on SPIRITS requirements 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 Jorge, I have a few comments and clarifications to add to your email, I have marked these with **JH in the text below (which is an extract from your orginal email): Extract of email begins " 1) TDPs setting (Igor's question). According to the ITU-T standards, the SMS could be used to set the desired TDPs in the SSPs. However, the SMSs from some suppliers are not able to do so. In some cases an access to the SSP is done via a different nodes (e.g. used for operation and maintenance of the switch). **JH Could you please explain the first sentence, what you mean by the ITU-T standards (which ones?) and the Short Message Service being used to set triggers. First, why and second, which types of SMS, orginating or terminating or both? Third, what is the service we are trying to achieve here and finally what are the restrictions to which you refer? I am assuming you mean the GSM SMS. Unfortunately I did not receive the email from Igor that was dated 29th July so the context of your response to the questions from Igor is not clear to me.**JH I think we should let this as an implementation option. The requirement is that there exists a way to set the desired TDP in the correct SSF(s). This should be preferrably started from the SPIRITS Server (e.g. when the subscriber activates ICW subscription). 2) CAMEL DPs in SPIRITS (Igor's suggestion). I am not sure if we should add CAMEL DPs in the SPIRITS requirements. **JH I tend to agree with your comment my reasoning being that from the perspective of voice calls the DPs are just a subset of the ETSI Core INAP CS3 (as you are referring to CAMEL Phase 3 features). [Note that CAMEL does not use the DP specific approach but DP generic]. From the SPIRITS perspective, what service scenarios are being considered?? Is the CAMEL subscriber the SPIRITS served "user" and where is the CAMEL subscriber located, only in the PSTN?**JH In CAMEL phase 3, several types of "calls" are covered: a) Voice Calls. In this case no new DP is needed since CAMEL DPs are included in CS2. The only special case is the "Not Reachable" case which is mapped as a special cause in the Busy DP. Since we would receive the Busy DP parameters (if a SPIRITS service has subscribed to Busy), we would be able to distinguish a busy from a not reachable situation . b) USSD. This is not a PSTN call so it does not apply to SPIRITS. **JH Just a minor point, the interaction between the SCP and HLR is not IN but MAP (Mobile Application Part) and the USSD interaction in non call related **JH c) GPRS. Same comment. d) SMS. Same comment. **JH Just a minor point, CAMEL Phase 3 only supports triggering for Mobile Originated SMS, the terminating case will not be supported until the next Phase of CAMEL. Also, the SMS can be either via GPRS switched (in which case the triggering will be located in the SGSN) or MSC Switched (in which case the triggering will located in the MSC/VLR). **JH e) Mobility Management. This could allow a SPIRITS server to be notified in changed of location of a mobile user. However, triggering of these type of services is not based on DPs, but in a subscription mark in the HLR. **JH Just a clarification to the above statement, the use of subscription information in the HLR for triggering CAMEL services is not just restricted to Mobility Management but all types of "calls" listed above [Note that the HLR does not support an IN interface - does this matter for SPIRITS??]**JH Adding this to SPIRITS, means: i) Adding a requirement to allow setting subscription marks in the subscriber's HLR. This is equivalent to setting TDPs in the SSP (but in this case M-CSI is set in the HLR). **JH I think this is an over simplification. The HLR is not the SSP, it is the MSC/VLR which acts on this subscription information. These "triggers" are set by the HLR downloading the Camel Subscription information to the VLR on change of location, etc. In the case of Mobility Management, the changing of the M-CSI in the HLR achieves nothing until the new M-CSI is downloaded to the VLR where the triggering will actually occur. The notifications are sent to the gsmSCF by the VLR using the MAP protocol and not IN operations. How do you envisage this mechanism working in the Spirits environment and what sort of service scenario are you thinking of?? **JH ii) Mapping the CAMEL specific operations into events notification to the SPIRITS client. Since the SCP receives the information about the mobility state, this involves the C interface (is just an extension of the DP notification). **JH As stated above the operations are MAP not IN **JH I think this is useful for mobile networks and should be added to the requirements. What do you think ?. The events (not DPs!) which could be notified are: - Location Update in the same VLR service area. - Location Update in another VLR service area. - IMSI attach. - MS initiated IMSI detach. - Network initiated IMSI detach. **JH How do you envisage this information being used?? I assume you are only considering mobility of the user within the CS network but perhaps you could clarify. I do not believe that these mobility events will have meaning in an IP domain. **JH f) Supplementary Services Notification. This mechanism could allow a SPIRITS server to be aware of a subscriber having invoked one of the following supplementary services: Explicit Call Transfer, Call Deflection, Call Completion on Busy Subscriber or Multi-Party. It is also based on subscriptions marks in the HLR, but in this case I do not think this information can be used for SPIRITS services. **JH As with the Mobility Management these events are sent to the gsmSCF via the MAP protocol from the MSC. The IN protocol is not used. **JH "End of email extract. 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 Thu Sep 7 20:14: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 SMTP id UAA00497 for ; Thu, 7 Sep 2000 20:14: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 38515443E6; Thu, 7 Sep 2000 19:14:06 -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 330A8443DD for ; Thu, 7 Sep 2000 19:14:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Sep 7 20:12:45 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 91ACE44370; Thu, 7 Sep 2000 19:59:36 -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 600E544341 for ; Thu, 7 Sep 2000 19:59:36 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id TAA16074; Thu, 7 Sep 2000 19:59:35 -0400 Message-ID: <39B82BE0.A8E5E760@bell-labs.com> Date: Thu, 07 Sep 2000 19:59:28 -0400 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Subject: Re: [SPIRITS] More on SPIRITS requirements References: <80256953.00801D46.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 Jane, I believe the message Jorge referred to (anyway, it could be found on in the archive) is the one in which I was ruminating on setting DPs and mentioned TDPs. According to the ITU-T IN standard, this is done by the SMF statically; in the US Wireless IN standard, I understand it can be done dynamically. So, the gist of Jorge's reply is that it should be left to implementation. I agree. What that means is that SPIRITS (or, rather PINT, to be more precise) protocol will NOT postulate setting TDPs via SPIRITS client/PINT server. I hope this answers some of your questions. As for the usage of "SMS," I am absolutely sure Jorge uses it for Service Management System not "Short Message Service." Mea culpa: I suspect it was I who set the precedence in SPIRITS for this usage, which is wide-spread in the US OSS parlance. So SMS is really what Q.12x4 calls "SMF" (or Q.12x5, "SMP"). Now I think everything is clear. What is interesting is that the acronyms have become so overloaded ("What is IP--Internet Protocol or Intelligent Peripheral?" I was recently asked by a technical editor looking at a PINT picture in which IP marked BOTH. ) that I think we ought to use symbols rather than letter combinations. An ingenious idea: we could use Chinese characters! Respectfully, Igor Jane Humphrey wrote: > > Jorge, > ... > > > 1) TDPs setting (Igor's question). > > According to the ITU-T standards, the SMS could be used to set the desired > TDPs in the > SSPs. However, the SMSs from some suppliers are not able to do so. In some > cases an access > to the SSP is done via a different nodes (e.g. used for operation and > maintenance of the switch). > > **JH Could you please explain the first sentence, what you mean by the ITU-T > standards (which ones?) and the Short Message Service being used to set > triggers. First, why and second, which types of SMS, orginating or terminating > or both? Third, what is the service we are trying to achieve here and finally > what are the restrictions to which you refer? I am assuming you mean the GSM > SMS. Unfortunately I did not receive the email from Igor that was dated 29th > July so the context of your response to the questions from Igor is not clear to > _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits From spirits-admin@lists.bell-labs.com Fri Sep 8 04:27:03 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 SMTP id EAA18831 for ; Fri, 8 Sep 2000 04:27:02 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D6214438F; Fri, 8 Sep 2000 03:27:03 -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 0CF8244371 for ; Fri, 8 Sep 2000 03:27:01 -0400 (EDT) Subject: Re: [SPIRITS] More on SPIRITS requirements To: spirits@lists.bell-labs.com From: jgato@airtel.es Date: Fri, 8 Sep 2000 10:26:55 +0200 Message-ID: X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Version 5.0.2c (Esp.)|8 febrero del 2000) at 09/08/2000 10:26:59 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 EAA18831 Hi Jane, Thanks a lot for the comments. I think they are very useful to clarify many things. Let me try to clarify as much as I can. I will mark my comments with **JG. Please, feel free to send as many additional comments you may have. Regards, Jorge Gató Airtel Móvil Jorge, I have a few comments and clarifications to add to your email, I have marked these with **JH in the text below (which is an extract from your orginal email): Extract of email begins " 1) TDPs setting (Igor's question). According to the ITU-T standards, the SMS could be used to set the desired TDPs in the SSPs. However, the SMSs from some suppliers are not able to do so. In some cases an access to the SSP is done via a different nodes (e.g. used for operation and maintenance of the switch). **JH Could you please explain the first sentence, what you mean by the ITU-T standards (which ones?) and the Short Message Service being used to set triggers. First, why and second, which types of SMS, orginating or terminating or both? Third, what is the service we are trying to achieve here and finally what are the restrictions to which you refer? I am assuming you mean the GSM SMS. Unfortunately I did not receive the email from Igor that was dated 29th July so the context of your response to the questions from Igor is not clear to me.**JH **JG Igor has already clarified this. With SMS I did not mean GSM Short Message Service, but Service Management System. This is a name used to refer to the physical implementation of the Service Management Function (SMF) from IN ITU-T standards (Q.12XX). I apologyse for the confusion this has caused. I do not like using to many acronyms either (believe it or not)!**JG I think we should let this as an implementation option. The requirement is that there exists a way to set the desired TDP in the correct SSF(s). This should be preferrably started from the SPIRITS Server (e.g. when the subscriber activates ICW subscription). 2) CAMEL DPs in SPIRITS (Igor's suggestion). I am not sure if we should add CAMEL DPs in the SPIRITS requirements. **JH I tend to agree with your comment my reasoning being that from the perspective of voice calls the DPs are just a subset of the ETSI Core INAP CS3 (as you are referring to CAMEL Phase 3 features). [Note that CAMEL does not use the DP specific approach but DP generic]. From the SPIRITS perspective, what service scenarios are being considered?? Is the CAMEL subscriber the SPIRITS served "user" and where is the CAMEL subscriber located, only in the PSTN? **JH **JG If we base SPIRITS on the benchmark services, nothing from CAMEL is needed. Thinking about CAMEL is to prepare SPIRITS for future services for mobile users. You are right that CAMEL can refer to "circuit" subscribers and "packet" subscribers (GPRS). I was only thinking about "circuit" subscribers, since they are like "moving PSTN subscribers". I must recognise I have not though a lot of specific service scenarios. The only ones I have considered so far is replacing a fixed PSTN subscriber with a mobile subscriber in the benchmark services**JG In CAMEL phase 3, several types of "calls" are covered: a) Voice Calls. In this case no new DP is needed since CAMEL DPs are included in CS2. The only special case is the "Not Reachable" case which is mapped as a special cause in the Busy DP. Since we would receive the Busy DP parameters (if a SPIRITS service has subscribed to Busy), we would be able to distinguish a busy from a not reachable situation . b) USSD. This is not a PSTN call so it does not apply to SPIRITS. **JH Just a minor point, the interaction between the SCP and HLR is not IN but MAP (Mobile Application Part) and the USSD interaction in non call related **JH **JG Yes, you are totally right.**JG c) GPRS. Same comment. d) SMS. Same comment. **JH Just a minor point, CAMEL Phase 3 only supports triggering for Mobile Originated SMS, the terminating case will not be supported until the next Phase of CAMEL. Also, the SMS can be either via GPRS switched (in which case the triggering will be located in the SGSN) or MSC Switched (in which case the triggering will located in the MSC/VLR). **JH **JG Again, you are right.**JG e) Mobility Management. This could allow a SPIRITS server to be notified in changed of location of a mobile user. However, triggering of these type of services is not based on DPs, but in a subscription mark in the HLR. **JH Just a clarification to the above statement, the use of subscription information in the HLR for triggering CAMEL services is not just restricted to Mobility Management but all types of "calls" listed above [Note that the HLR does not support an IN interface - does this matter for SPIRITS??]**JH **JG Yes, I did not explain myself very well. What I meant is that the basic call (although based on a subscription mark in the HLR O-CSI, T-CSI, etc.) they refer to Detection Points (DPs) which can be mapped to the Basic Call State Models (BCSMs) used for PSTN. However, for Mobility Management this is not the case (we can say that they are call unrelated). In regards to the difference between MAP and INAP, I do not think this should matter for SPIRITS. In the scenarios we are talking about, both are used to access the SCP to trigger a service action. I agree this can affect the SPIRITS architecture and some work would be needed there (minor clarification could be enough).**JG Adding this to SPIRITS, means: i) Adding a requirement to allow setting subscription marks in the subscriber's HLR. This is equivalent to setting TDPs in the SSP (but in this case M-CSI is set in the HLR). **JH I think this is an over simplification. The HLR is not the SSP, it is the MSC/VLR which acts on this subscription information. These "triggers" are set by the HLR downloading the Camel Subscription information to the VLR on change of location, etc. In the case of Mobility Management, the changing of the M-CSI in the HLR achieves nothing until the new M-CSI is downloaded to the VLR where the triggering will actually occur. The notifications are sent to the gsmSCF by the VLR using the MAP protocol and not IN operations. How do you envisage this mechanism working in the Spirits environment and what sort of service scenario are you thinking of?? **JH **JG You have explained very well how the Mobility Management triggers work. I do not see a difference between setting the M-CSI from a CAMEL Operations Centre than from a SPRITS service node. In both cases, the HLR should notify the VLR of the new subscriber profile (if I remeber well an InsertSubscriberData MAP operation should be sent from the HLR to the VLR). The service scenario that I see is integrating mobility and location into SPIRITS service. For example, for Internet Call Waiting, the treatment of an incoming call could be "send to my mobile if attached, otherwise take the call and release the internet session".**JG ii) Mapping the CAMEL specific operations into events notification to the SPIRITS client. Since the SCP receives the information about the mobility state, this involves the C interface (is just an extension of the DP notification). **JH As stated above the operations are MAP not IN **JH **JG Correct.**JG I think this is useful for mobile networks and should be added to the requirements. What do you think ?. The events (not DPs!) which could be notified are: - Location Update in the same VLR service area. - Location Update in another VLR service area. - IMSI attach. - MS initiated IMSI detach. - Network initiated IMSI detach. **JH How do you envisage this information being used?? I assume you are only considering mobility of the user within the CS network but perhaps you could clarify. I do not believe that these mobility events will have meaning in an IP domain. **JH **JG You are right. I only meant "circuit" subscribers. I do not think that even SPIRITS apply to "packet" subscribers. f) Supplementary Services Notification. This mechanism could allow a SPIRITS server to be aware of a subscriber having invoked one of the following supplementary services: Explicit Call Transfer, Call Deflection, Call Completion on Busy Subscriber or Multi-Party. It is also based on subscriptions marks in the HLR, but in this case I do not think this information can be used for SPIRITS services. **JH As with the Mobility Management these events are sent to the gsmSCF via the MAP protocol from the MSC. The IN protocol is not used. **JH **JG Correct.**JG "End of email extract. 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 Thu Sep 21 12:18:18 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 SMTP id MAA09156 for ; Thu, 21 Sep 2000 12:18:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E47DE4439F; Thu, 21 Sep 2000 11:18:08 -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 42E5044338 for ; Thu, 21 Sep 2000 11:18:06 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Sep 21 12:16:18 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 2341244380; Thu, 21 Sep 2000 12:03:09 -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 EB48944341 for ; Thu, 21 Sep 2000 12:03:08 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA08084; Thu, 21 Sep 2000 12:03:08 -0400 Message-ID: <39CA3122.8FFC32D9@bell-labs.com> Date: Thu, 21 Sep 2000 12:02:42 -0400 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: spirits@lists.bell-labs.com Cc: lslutsman@att.com, hui-lan.lu@bell-labs.com, a.brusilovsky@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 Jorge, I am updating the requirements and I plan to issue the .01 version tomorrow. I will definitely send you a copy today BEFORE I send it to the IETF, but so far I just made sure that I put ALL your suggestions in. In any event, I will issue another copy no later than a month from now. One thing I need from you urgently is your address and telephone number because I need to put them in the draft. With best regards, 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 Sep 22 08:26: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 SMTP id IAA11573 for ; Fri, 22 Sep 2000 08:26: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 8B1DD4437A; Fri, 22 Sep 2000 07:26:06 -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 6CEB344338 for ; Fri, 22 Sep 2000 07:26:04 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Sep 22 08:24:36 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 991D14437D; Fri, 22 Sep 2000 08:11:26 -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 5C29944341 for ; Fri, 22 Sep 2000 08:11:26 -0400 (EDT) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id HAA24417; Fri, 22 Sep 2000 07:11:07 -0500 Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id HAA24407; Fri, 22 Sep 2000 07:11:05 -0500 Message-ID: <39CB4CE0.79511199@lucent.com> Date: Fri, 22 Sep 2000 07:13:21 -0500 From: Alec Brusilovsky X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: SPIRITS list Content-Type: multipart/mixed; boundary="------------C04E335FE35A62C1287E4D7F" Subject: [SPIRITS] IESG approval 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. --------------C04E335FE35A62C1287E4D7F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear members of the SPIRITS WG, Our AD just informed Steve and I that IESG has approved our "Pre-Spirits Implementations of PSTN-initiated Services" document. We reached our first WG milestone! Congratulations to Hui-Lan Lu (Document Editor) and the whole group of authors! Regards, Alec --------------C04E335FE35A62C1287E4D7F 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 --------------C04E335FE35A62C1287E4D7F-- _______________________________________________ SPIRITS mailing list SPIRITS@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/spirits