rfc3298.txt

RFC 的详细文档！

   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
                      |                   |
                                          |
                                          |