File: rfc3298.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (955 lines) | stat: -rw-r--r-- 36,560 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955






Network Working Group                                I. Faynberg, Editor
Request for Comments: 3298                           Lucent Technologies
Category: Informational                                          J. Gato
                                                               Vodaphone
                                                                   H. Lu
                                                     Lucent Technologies
                                                             L. Slutsman
                                                                    AT&T
                                                             August 2002


  Service in the Public Switched Telephone Network/Intelligent Network
 (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document describes the SPIRITS protocol requirements, based on
   the architecture presented in RFC 3136.  (SPIRITS stands for "Service
   in the PSTN/IN Requesting InTernet Service".)  The purpose of the
   protocol is to support services that originate in the Public Switched
   Telephone Network (PSTN) and necessitate the interactions between the
   PSTN and the Internet.  Similarly, such services are called SPIRITS
   services.  (Internet Call Waiting, Internet Caller-ID Delivery, and
   Internet Call Forwarding are examples of SPIRIT services, but the
   protocol is to define the building blocks from which many other
   services can be built.)  On the PSTN side, the SPIRITS services are
   initiated from the Intelligent Network (IN) entities; the earlier
   IETF work on the PSTN/Internet Interworking (PINT) resulted in the
   protocol (RFC 2848) in support of the services initiated the other
   way around--from the Internet to PSTN.

   To this end, this document lists general requirements for the SPIRITS
   protocol as well as those pertinent to IN, Wireless IN, and PINT
   building blocks.  The document also presents the SPIRITS WG consensus
   on the choice of the SPIRITS signaling protocol.






Faynberg, et al.             Informational                      [Page 1]

RFC 3298             SPIRITS Protocol Requirements           August 2002


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.

   Unless otherwise qualified, the term PINT is used here not to refer
   to the present PINT services and protocol, but in reference to the
   scope of the generic PINT (vs. SPIRITS) service characteristics--
   services being invoked from an IP network (vs. PSTN).

2. Introduction

   This document describes the SPIRITS protocol requirements, based on
   the architecture presented in RFC 3136.  (SPIRITS stands for "Service
   in the PSTN/IN Requesting InTernet Service.")  The purpose of the
   protocol is to support services that originate in the Public Switched
   Telephone Network (PSTN) and necessitate the interactions between the
   PSTN and the Internet.  Such services are called SPIRITS services.
   (Internet Call Waiting, Internet Caller-ID Delivery, and Internet
   Call Forwarding are examples of SPIRIT services, but the protocol is
   to define the building blocks from which many other services can be
   built.)  On the PSTN side, the SPIRITS services are initiated from
   the Intelligent Network (IN) entities; the earlier IETF work on the
   PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848)
   in support of the services initiated the other way around--from the
   Internet to PSTN.

   To this end, this document lists general requirements for the SPIRITS
   protocol as well as those pertinent to IN, Wireless IN, and PINT
   building blocks.  The document also presents the SPIRITS WG consensus
   on the choice of the SPIRITS signaling protocol.  The joint
   PINT/SPIRITS architecture (described in [1]) is depicted in Figure 1.

   It is assumed that the Spirits Client is either co-located with the
   IN Service Control Function (SCF) or communicates with it (over the
   PSTN-specific interface D) in such a way so as to act on behalf of
   the PSTN/IN.  (This assumption is confirmed by current
   implementations, as reported in [2].)

   The SPIRITS services are invoked (and, subsequently, the SPIRITS
   protocol is initiated) when a message from a SPIRITS Client (located
   in the IN Service Control Point [SCP] or Service Node [SN]) arrives
   on interface C to the SPIRITS gateway.  The Spirits gateway processes
   the message and, in turn, passes it on over the Interface B to the
   SPIRITS server.  In most practically important cases, the request
   from a SPIRITS client is ultimately caused by a request from a
   Central Office (i.e., a telephone switch) sent to either the SCP or



Faynberg, et al.             Informational                      [Page 2]

RFC 3298             SPIRITS Protocol Requirements           August 2002


   SN, although the Internet-based service initiation by these elements
   that had not been triggered by the Central Office is theoretically
   possible.  (Definitely, none of the SPIRITS benchmark services are
   initiated in such a way, so, for the purposes of the SPIRITS protocol
   development, it should be assumed that the service invocation was a
   direct result of an earlier action by the Service Switching
   Function.)












































Faynberg, et al.             Informational                      [Page 3]

RFC 3298             SPIRITS Protocol Requirements           August 2002


                                      ......................
      +----------------+              .                    .
      | +------------+ |              .   +------------+   .
      | |            | |       A      .   |            |   .
      | | PINT Client|********************|PINT Server/|********
      | |            | |              .   |  Gateway   |       *
      | +------------+ |              .   +------------+   .   *
      |                |              .                    .   *
      |  Subscriber's  |              .                    .   *
      |                |              .                    .   *
      |  IP Host       |              .                    .   *
      |                |              .   +------------+   .   *
      | +------------+ |              .   | SPIRITS    |   .   *
      | | SPIRITS    | |       B      .   | Gateway    |   .   *
      | | Server     |********************|            |   .   * E
      | |            | |              .   +------------+   .   *
      | +------------+ |              .          *         .   *
      +----------------+              .          *         .   *
                                      ...........*..........   *
                                                 *             *
                                                 *             *
           Subscriber's                          *  C          *
           Telephone                             *             *
                                                 *             *
             (---)                               *             *
               *                                 *             *
              * *                                *             *
     ++++++++++++++++++++++++++  PSTN   ++++++++++++++++++++++++++
               *                                 *             *
               *                                 *             *
               *                          +------------------+ *
               * Line                     | SPIRITS Client   | *
               *                          |                  | *
      +--------------------+          +---+----- D  ---------+-*+
      |                    | INAP/SS7 |                         |
      |Service Switching   ************Service Control Function |
      |    Function        |          |                         |
      |                    |          +-------------------------+
      |                    |
      |                    |
      +--------------------+

             Figure 1. Joint PINT/SPIRITS Architecture








Faynberg, et al.             Informational                      [Page 4]

RFC 3298             SPIRITS Protocol Requirements           August 2002


   With PINT (and that also applies to the PINT architecture and
   protocol as described in [3]), the service request to the PINT Server
   is always initiated by the PINT Client over the interface A.  The PINT
   Server can either be co-located with the IN Service Control or a
   similar entity (referred to as "Executive System" by [3]) or
   communicate with it over the PSTN-specific interface E.

   As Figure 1 shows, the PINT Client and SPIRITS Server are co-located
   in Subscriber's IP Host.  In fact, both can be implemented to run as
   one process.  No provision is made for interactions between the PINT
   Client and Spirits Server.  Similarly, the PINT Server/PINT Gateway
   and SPIRITS gateway are assumed to be co-located, too.  This
   assumption is convenient but not essential; the PINT Server could
   also be co-located with the SPIRITS Client.  In either case, no
   specific provision is made to define interworking between either the
   PINT Server and Spirits Gateway or PINT Server and SPIRITS Client
   other than by listing the overall PINT-related requirements.

   Since the currently deployed worldwide wireless networks are based on
   circuit switching, they are considered PSTN networks for the SPIRITS
   purposes.  Adding SPIRITS type of services to wireless networks can
   allow new services to be developed (for example geolocation
   information can be handled in the IP network).

   Nevertheless, there are certain peculiarities of wireless networks,
   which force considerations to be made in the protocol
   requirements and in the SPIRITS architecture.

   A particular Wireless IN standard development being considered here
   is CAMEL phase 3, standardized by the Third Generation Partnership
   group (3GPP).  The relevant service and architectural considerations
   and protocol requirements are presented later in this document.  As
   far as the architecture is concerned, certain wireless events are
   generated by Home Location Register (HLR), which may, but does not
   have to, be part of the Mobile Switching Center (MSC) (a wireless
   equivalent of the SSP).  These events are communicated to Service
   Control, at which point they use the same mechanism for invoking
   SPIRITS services that the IN would.

   The rest of this document addresses the general requirements,
   IN Requirements, specific Wireless IN requirements, PINT
   Requirements, the protocol development methodology, and security
   issues, in that order.








Faynberg, et al.             Informational                      [Page 5]

RFC 3298             SPIRITS Protocol Requirements           August 2002


3. General Requirements

   Based on the success of extending SIP for PINT ([3]) and, especially,
   the results of pre-SPIRITS implementations reported in [2], the
   Session Initiation Protocol (SIP) [7] has been chosen as the
   signaling base protocol for SPIRITS.

   Thus, it is a requirement that specific SPIRITS-related parameters be
   carried in a manner consistent with SIP practices.  In particular,
   either Session Description Protocol (SDP) [8] or Multi-purpose
   Internet Mail Extensions MIME [5-6] may be used for this purpose.
   Except for the proposed new SUBSCRIBE/NOTIFY mechanism [4], and
   extensions already defined in PINT, no new SIP extensions are
   foreseen; instead the SPIRITS protocol is to rely on the above
   extension mechanisms.

   It is by no means a requirement that any SPIRITS implementation
   automatically support PINT services.  The SPIRITS protocol must be
   defined in a manner where, as the minimum, it can support only the
   basic notification mechanism without relying on PINT services or
   otherwise relying on persistent interactions with PSTN.
   Nevertheless, it has been demonstrated [2] that combining PINT
   building blocks with those of SPIRITS is beneficial to building rich,
   enhanced PSTN/Internet services, so the SPIRITS protocol must meet
   the PINT-related requirements listed in section 7 of this document.

   One specific example demonstrating the application of the latter
   requirement, which is elaborated on further in this document, is as
   follows: Implementation of SUBSCRIBE/NOTIFY is not mandatory as far
   as the minimum SPIRITS protocol is concerned.  Thus, the initial PSTN
   (Detection Point) notification will always arrive via the SIP INVITE
   method; however, to implement persistent interactions with the PSTN,
   the SUBSCRIBE method may be used to obtain further notifications of
   the PSTN events.  Subsequently, these events will be reported on by
   means of the NOTIFY method.

4. IN Requirements

   The interface immediately relevant to IN is that between the SPIRITS
   Client and SPIRITS Gateway (interface C).  A typical message (which
   starts a SPIRITS service) looks like this:

   C -> G: <Event Notification>, <Parameter-List (DP)>

   The relevant events correspond to the detection points (DPs) of the
   IN Basic Call State Model (BCSM).  The <Parameter-List> is a function
   of a specific DP; it contains the parameters relevant to it.  The
   following requirements apply:



Faynberg, et al.             Informational                      [Page 6]

RFC 3298             SPIRITS Protocol Requirements           August 2002


   1) The list of the DPs to be covered encompasses those defined in the
      IN Capability Set 3 BCSM as well as those which relate to the
      Wireless IN (WIN) specified by the IMT 2000 project in ITU-T.

   2) Not all parameters associated with such DPs are needed by the
      SPIRITS benchmark services, nor may all the parameters be needed
      in SPIRITS.  The selection of the relevant parameters is part of
      the SPIRITS protocol definition.

   3) It is desirable to avoid semantic overload of protocol messages.
      (One way to achieve that is to match each type of an event with a
      message that corresponds to it.)  As the SPIRITS protocol is
      designed as a set of extensions to another (existing) protocol
      with the defined message set, the syntax and semantics of the
      extensions should be defined with this requirement in mind.

   4) The ITU-T Recommendations use the abstract syntax notation (ASN.1)
      to specify the semantics of the IN Application Protocol (INAP)
      parameters, which are expected to be binary-encoded.  Neither the
      use of the ASN.1, nor the requirement for binary encoding are the
      typical requirements for the IETF application protocols.
      Recognizing that, provisions must be made for careful
      specification of the conversion of the INAP parameters to text,
      which must preserve their original semantics.  The actual
      conversion of the parameters is the function of the SPIRITS
      Client.

      In order to issue an initial query (or a notification) to service
      control, a switch must have such a DP set.  This can be done
      statically via service management (this particular action should
      be left to implementation and thus is considered outside of the
      scope of SPIRITS Protocol) or dynamically--but only for the
      purpose of a particular call--from the service control.  In the
      latter case, it is part of the SPIRITS (or PINT) protocol to
      request the event notification from the service control.  The SIP
      specific event notification scheme [4] should be specifically
      considered.  This function can be performed by either the Spirits
      Client or PINT Server, the distinction being further discussed in
      the next section.  Assuming that it is performed by the SPIRITS
      Client, the relevant message should look like:

      G->C: SUBSCRIBE <Event> <Mode> <DP-specific parameters>,

      where <Event> refers to a particular DP; <Mode> determines whether
      the Event Detection Point (EDP) is to be armed as EDP Request
      (EDP-R), EDP Notification (EDP-N), or TDP-R (the need for TDP-N is
      not foreseen because it would not provide any additional
      capability for SPIRITS); and the <DP-specific parameters> is the



Faynberg, et al.             Informational                      [Page 7]

RFC 3298             SPIRITS Protocol Requirements           August 2002


      list of the values of the parameters associated with the EDP (for
      example, if the DP in question is O_No_Answer, then the value of
      the appropriate timer should be included in the list).  Note that
      such a subscription may also originate at a) PINT Client or b)
      SPIRITS Gateway, either of which may (but does not have to) have a
      locally significant definition of the <Event>.  In either case, it
      is the function of the SPIRITS Client to translate the definition
      of the Event into a particular DP (or set of DPs) when passing the
      message to Service Control.  To summarize, for the case when PINT
      and SPIRITS events are defined in a way where they do not refer to
      the BCSM DPs, it is the function of the SPIRITS Client to define a
      mapping:

      Event -> DP List,

      for each event for which the PSTN notification is needed.

      The list of CS-3 DPs envisioned in SPIRITS is:

      -  origination_attempt_authorized (the SPIRITS service can control
         call attempts, (for example, to limit calls during specific
         time periods)

      -  collected_information and analyzed_information (for SPIRITS
         outgoing call screening)

      -  o_answer, o_term_seized, and t_answer (to release SPIRITS
         resources after the call is complete and perform relevant OA&M
         actions such as creating a record of attempts to reach a party
         via various means like land-line phone, cell phone, SMS, or
         paging.)

      -  o_no_answer, route_select_failure, and t_no_answer (to re-route
         a call)

      -  o_called_party_busy (to re-route a call and for Internet Call
         Waiting)

      -  o_mid_call and t_mid_call (to assist a midcall action)

      -  o_abandon, o_disconnect, t_abandon, and t_disconnect  (to
         terminate a SPIRITS service and release the resources and
         perform relevant OA&M actions such as creating a record of
         attempts to reach a party via various means like land-line
         phone, cell phone, SMS, or paging.)






Faynberg, et al.             Informational                      [Page 8]

RFC 3298             SPIRITS Protocol Requirements           August 2002


   In addition, the following DPs are relevant to the present SPIRITS
   milestone services:

      - termination_attempt_authorized

      - facility_selected_and_available (could be used in SPIRITS
         Internet Caller-ID)

      - t_busy (for Internet Call Waiting and Call Forwarding).

5. Wireless-IN-related Requirements

   Wireless IN covers several types of "calls," which are neither
   circuit switched nor have an effect on circuit switched calls.  For
   this reason, those are not considered in SPIRITS requirements.  To
   further clarify this point, the types of "calls" not considered are:

      -  USSD (Unstructured Supplementary Service Data)

      -  GPRS (General Packet Radio System)

      -  SMS (Short Message System)

         The types of calls relevant to SPIRITS are as follows:

      a) Voice Calls.  In this case no new DP is needed since CAMEL DPs
         are included in CS2.  The only special case is "Not Reachable"
         (when it is detected that the mobile user is out of coverage or
         has switched off), which is mapped as a special cause in the
         Busy DP.  Since the Busy DP parameters would be received (if a
         SPIRITS service has subscribed to Busy), it would be possible
         to distinguish a "busy" from a "not reachable" situation.

         This translates into the requirement that one of the parameters
         in the Event Notification message (from SPIRITS Client to
         SPIRITS Gateway, over the interface C) denotes the "cause" for
         the Busy Detection Point.

         Another aspect of difference, when compared to PSTN, is setting
         of static DPs.  In CAMEL networks, this is done in the Home
         Location Register (HLR) (and copied to the VLR during location
         update).  It is important to note this difference, even though
         it has no effect on  SPIRITS protocol.








Faynberg, et al.             Informational                      [Page 9]

RFC 3298             SPIRITS Protocol Requirements           August 2002


      b) Mobility Management events.  This allows a SPIRITS server to be
         notified of changes of location of a mobile user.  The events
         would only be applicable to mobile users reachable through a
         Circuit-Switched network.  To provide for this function, the
         subscription marks must be set in the subscriber's HLR.  This
         is equivalent to setting TDPs in the SSP.  In this case, the
         marks in the HLR (which are copied to the Visitor Location
         Register [VLR] on location update) are not mapped into Trigger
         Detection Points.

         As with TDP setting, this is outside of the scope of SPIRITS
         protocol.

         In order to support this function in SPIRITS, the SPIRITS
         protocol should be able to map 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.  (This is just an extension of the DP
         notification mechanism from the SPIRITS client to the SPIRITS
         gateway).

         The events (which are not DP-related) which need notifications
         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.

         With this mechanism, the SPIRITS services can use the user-
         profile-based location information.  For example, the Internet
         Call Waiting service can re-direct the call to a mobile phone.

      c) Supplementary Services Notification.

         This mechanism makes a SPIRITS server 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.







Faynberg, et al.             Informational                     [Page 10]

RFC 3298             SPIRITS Protocol Requirements           August 2002


6. PINT-related Requirements

   Before a SPIRITS service can be invoked, the relevant IP Host must be
   registered.  Thus, Registration is an essential service, which is
   initiated from the IP side.  The registration information is
   ultimately used by the PSTN to authenticate the subscriber.

   Depending on the model, this can be done in two ways with the present
   architecture:

   1) The PINT Client issues the appropriate Register message over the
   interface A, which is then passed by the PINT server to the SPIRITS
   Gateway and SPIRITS Client:

   PINT C.: -- Register --> PINT S. [--> SPIRITS Gateway --> SPIRITS
   C.].  In this case the SPIRITS Client (co-located with the service
   control) is responsible for record keeping and the authentication.

   2) The PINT Client issues the appropriate Register message to the
   PINT Server, which then passes this information to the PSTN service
   control "by magic".

   The second model is much easier to handle, because it involves only
   one relevant interface ("A"); however it assumes no interworking
   between PINT and SPIRITS except that the SPIRITS Client finds "by
   magic" that a friendly and expecting IP Host is alive and well.

   Finally, in the event PINT is not implemented, the SIP SUBSCRIBE
   mechanism can be used.

   As noted in the previous section, the existing SUBSCRIBE/NOTIFY PINT
   building blocks [3] must be extended for their use in SPIRITS for the
   purposes of setting DPs/getting DP event notifications.  (A more
   general SIP mechanism for the same PINT-introduced block is described
   in [4]; it provides the necessary mechanism for specifying relevant
   events.)  Conversely, the same building blocks for the functional
   capabilities can be used in both PINT and SPIRITS protocols.  Note,
   however, that in SPIRITS the PSTN notification may arrive without a
   particular subscription to an event (in the case of a statically set
   DP).

7. Follow-up on Event Notifications

   The requirements of this section are neither PINT-specific, nor IN-
   specific; their role is to outline the remaining element necessary
   for the delivery of the SPIRITS service, which is the reaction to the
   notification received.




Faynberg, et al.             Informational                     [Page 11]

RFC 3298             SPIRITS Protocol Requirements           August 2002


   In a particular scenario where:

      a)  The IP subscriber registers a SPIRITS service;

      b)  A call triggering the SPIRITS service is received (and
         notification is sent); and

      c) The call disposition is performed by the end user, the
         signalling flow is demonstrated in Figure 2.

                      |---->  Registration  ----->|
              SPIRITS |<-- Event Notification <-- | SPIRITS
              Gateway |---> Call Disposition ---->| Client
                      |                   |
                                          |
                                          |
                                          |
                                          V
                                    Service Control
                                          |
                                          |
                                          V
                                         SSP

                 Figure 2: Sequence of SPIRITS actions

   One of the following actions is required by benchmark services:

      a) Accept the incoming call

      b) Reject the incoming call

      c) Redirect the incoming call

      d) Accept the call via VoIP (this particular item is outside of
         the scope of SPIRITS WG).

   Accordingly, the SPIRITS protocol should define the following message
   types:

      a) S->G: <Accept Call>

      b) S->G: <[Reject Call],[Cause]>

      c) S->G: <[Redirect Call],[Redirection Destination]>






Faynberg, et al.             Informational                     [Page 12]

RFC 3298             SPIRITS Protocol Requirements           August 2002


8. Methodology

   To determine the MINIMUM SPIRITS protocol vocabulary (i.e., the set
   of messages), the PSTN events associated with each detection point of
   the Basic Call State Model should be examined.  To date, the CS-3
   BSCM has the richest set of DPs, although not all switching exchanges
   have implemented it.

   To determine the MINIMUM information available to the SPIRITS client
   (this information is to be carried by the SPIRITS protocol from
   SPIRITS client to SPIRITS server), each DP-specific information
   elements needs to be examined.

   Parameters should be event-specific, the following generic types of
   parameters are expected to be mandatory:

      - timer (for no answer)

      - midcall control info (for mid_call)

      - number of digits (for collected_information)

9. Security Considerations

   Overall, the basic aspects of security apply to SPIRITS protocol:

   -  Authentication:
      In the communications between the SPIRITS Client and SPIRITS
      Gateway as well as the SPIRITS Gateway and SPIRITS Server, it is
      required that the information be sent between known and trusted
      partners.

   -  Integrity:
      It is a requirement that no exchanged data be modified in transit.

   -  Confidentiality:
      It is a requirement that any private user information or
      confidential network data be protected by the protocol (typically
      through encryption, for which the protocol should allow a choice
      in the algorithm selection.

   -  Availability:
      It is a requirement that the communicating endpoints remain in
      service for authorized use only.







Faynberg, et al.             Informational                     [Page 13]

RFC 3298             SPIRITS Protocol Requirements           August 2002


   In addition, the protocol should support non-repudiation for those
   control messages pertinent to charging the PSTN subscriber.

   As Figure 1 demonstrates, there are two distinct communications
   interfaces, B and C.  The B interface is, in general, across the
   public Internet and is thus most vulnerable to security attacks
   resulting in theft or denial of service.  The C interface, on the
   other hand is likely to be implemented across a service providers
   intranet, where the security measures should be applied at the
   discretion of the service provider.  Even then, because at least one
   IP host (the PINT gateway) is connected to the Internet, special
   measures (e.g., installation of firewalls, although this particular
   measure alone may be insufficient) need to be taken to protect the
   interface C and the rest of the network from security attacks.

   The assumption that the PINT Client and SPIRITS server are co-
   located, dictates that the security considerations for the A and B
   interfaces are exactly same.  Detailed security requirements and
   solutions for interface A (and, consequently, B) can be found in RFC
   2848 [3].

   Possible security attacks can result in both theft and denial of
   services.  In addition, such attacks may violate the privacy of a
   PSTN subscriber.  For example, with Internet Call Waiting, a
   fraudulent registration (or a manipulation of integrity of a valid
   registration) may force a network operator to provide to an
   authorized party a full log of attempted telephone calls (accompanied
   by the identification of callers).  Furthermore, the calls may be
   diverted to wrong recipients (who may further defraud the
   unsuspecting calling party).  In this case, the calling party is
   using only the PSTN and thus expecting the security of communications
   that are typical of the PSTN.  The PSTN service providers may be
   liable for the consequences of establishing wrong connections.  In
   addition, the PSTN service providers may be liable for inadvertent
   divulging of the private information of the subscriber.

   The service and network providers need to review the possibilities of
   the security attacks and prepare the means of protection from them.
   Some of this may be achieved by using the means outside of those
   provided by the protocol itself.  For example, administrative
   information (such as statistics collected by PINT MIB or SPIRITS MIB)
   can help in determining violations and thwarting them.  As far as the
   protocol is concerned, it must provide the means for authenticating a
   subscriber as well as a session.  It must also provide a capability
   to carry encrypted information in its body.






Faynberg, et al.             Informational                     [Page 14]

RFC 3298             SPIRITS Protocol Requirements           August 2002


10. Acknowledgements

   The authors are grateful to all participants in the SPIRITS group for
   the discussion that has been shaping this work.  Many thanks go to
   Jorgen Bjorkner, Alec Brusilovsky, Jim Buller, Lawrence Conroy, Soren
   Nyckelgard, and John Voelker for their incisive comments.  Special
   thanks are to Vijay Gurbani, Dave Hewins, and Kumar Vemuri, whose
   careful, detailed reviews of several versions of this document have
   been particularly helpful in improving its quality.

11. References

   [1] Slutsman, L., Faynberg, I., Lu, H. and M. Weissman, "The Spirits
       Architecture", RFC 3136, June 2001.

   [2] Lu, H. (Editor), Faynberg, I., Voelker, J., Weissman, M., Zhang,
       W., Rhim, S., Hwang, J., Ago, S., Moeenuddin, S., Hadvani, S.,
       Nyckelgard, S., Yoakum, J. and L. Robart, "Pre-SPIRITS
       Implementations of PSTN-Initiated Services", RFC 2995, November
       2000.

   [3] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions
       to SIP and SDP for IP Access to Telephone Call Services", RFC
       2848, June 2000.

   [4] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
       Notification", RFC 3265, June 2002.

   [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part One: Format of Internet Message Bodies",
       RFC 2045, November 1996.

   [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
       Extensions (MIME) Part Two: Media Types", RFC 2046, November
       1996.

   [7] Handley, M., Schooler, E., Schulzrinne, H. and J. Rosenberg,
       "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [8] Handley, M. and  V. Jacobsen, "SDP: Session Description
       Protocol", RFC 2327, April 1998.










Faynberg, et al.             Informational                     [Page 15]

RFC 3298             SPIRITS Protocol Requirements           August 2002


12. Authors' Addresses

   Lev Slutsman
   AT&T Laboratories
   200 Laurel Ave.
   Middletown, New Jersey, 07748

   Phone: (732) 420-3752
   EMail: lslutsman@att.com


   Igor Faynberg
   Bell Labs/Lucent Technologies
   Room 4D-601A, 101 Crawfords Corner Road
   Holmdel, New Jersey, 07733

   Phone: (732) 949-0137
   EMail: faynberg@lucent.com


   Jorge Gato
   Vodaphone
   Avda de Europa, 1.
   28108 Alcobendas (Madrid). Spain

   Phone: +34 607 13 31 10
   Fax:   +34 607 13 30 57
   EMail: jgato@airtel.es


   Hui-Lan Lu
   Bell Labs/Lucent Technologies
   Room 4C-607A, 101 Crawfords Corner Road
   Holmdel, New Jersey, 07733

   Phone: (732) 949-0321
   EMail: huilanlu@lucent.com














Faynberg, et al.             Informational                     [Page 16]

RFC 3298             SPIRITS Protocol Requirements           August 2002


13.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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 languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Faynberg, et al.             Informational                     [Page 17]