Subject: [SPIRITS] Spirits meeting notes [Draft]

From: Alec Brusilovsky <[email-masked]>
Date: Sun, 20 Aug 2000 21:19:34 -0500

Group,

Please see attached...

-Alec
48th IETF SPIRITS Working Group Meeting Notes

Reported by Alec Brusilovsky.
Recorded by Kumar Vemuri, to whom both co-chairs express their deepest
appreciation for the job well done.

SPIRITS WG met on the morning of Monday, July 31, 2000.
There were 110 registered attendees.

Chairs: Steve Bellovin, Alec Brusilovsky

Agenda

1. Agenda bashing and goals of the session
    - Alec Brusilovsky - 5 minutes;
2. Progress of Implementation RFC
    - Hui-Lan Lu - 10 minutes;
3. SPIRITS progress in ITU-T
    - Hui-Lan Lu - 5 minutes;
4. Discussion on the proposed SPIRITS Architecture
    - Lev Slutsman - 25 minutes;
5. Discussion on the SPIRITS Protocol Requirements, including:
            a. Building blocks  - and how they define requirements
                for the Protocol - Lawrence Conroy - 15 minutes
            b. IN and PINT related SPIRITS Protocol Requirements
                - Igor Faynberg - 15 minutes;
            c. SPIRITS Protocol Requirements leading to the Protocol
                selection - Jörgen Björkner - 15 minutes;
6. Wrap-up - 5 minutes.

Steve Bellovin opened the meeting with the announcement and IETF disclaimer, regarding Intellectual Property Rights as they relate to discussions at public meetings at the IETF.

1. Alec Brusilovsky started with the Agenda:
Changes in the agenda, since Lev Slutsman could not attend, Igor Faynberg will be the substitute and would cover both Architecture, as well as Protocol Requirements parts.

2. Progress of implementation document, Hui-Lan Lu.
Revised version of the implementation RFC is available from the official IETF directory. This version has incorporated all the comments from the mailing list:
o Changes to the implementation flows with simpler examples
o Better definition of the term "Spirits server"
o Automatic Incoming call disposition includes intelligent profiles and private call treatment
o Clarification of VersionInfoAck.

3. ITU-T liaison information (Hui-Lan Lu)
The last Rapporteur's meeting had no specific discussion of Spirits. SPIRITS related   information will be submitted to future ITU-T meetings.

4. Alec B. on Discussion of the Spirits Architecture. Alec talked about WG's charter and milestones, Alec asked everyone to follow a focused discussion on architecture and protocols. 

Igor (presented) work done with J Gato, L. Slutsman, H. Lu, M. Weissman

  Introductory comments - issues agreed on: 
     IP side must know the information that comes with the PSTN 
     service requesting messages, and it must know the responses
     the PSTN expects, and what attributes are required.

  Architecture picture: 
     Showed Spirits Client near PSTN/IP boundary, and IP connections
     from this entity to a Spirits proxy via Interface C. This proxy
     is connected to the Spirits server via Interface B. Similarly, 
     there is a PINT server (a peer of the Spirits proxy - could be 
     co-located with it) that interfaces to the PINT client via 
     Interface A. Igor made a reference to Softswitches as elements 
     that could implement one or more of these services.
    
     Interface between Spirits Proxy and the Spirits Client is IN-like.
     General PINT-aligned interfaces are located between the Sprits 
     proxy and the Spirits server.

     Registration and subscribe/notify building blocks are used in
     PINT interface A, this may be needed with some modifications for
     Spirits with capabilities for DP-arming etc., Some notifications
     could be subscribed to, but, other out of the blue notifications
     would also need to be supported.

     Issue: Is it a requirement that if PINT is implement, Spirits is also
     implemented? 
     Answer: Not necessary. Subscribe/notify may be commonly used
     building block in both cases, but there are no requirements that
     if one is used, then the other must be supported. Interface B does
     not have to necessarily know details of the PSTN implementation.
     
     Issue: Spirits takes into account Wireless IN DPs etc., Brief 
     discussion on IN - the originating and terminating call models 
     then follows:

     Issue: One of the possible service scenarios: Spirits proxy sends 
     a subscribe for an event to a Spirits Client that then communicates 
     with the SCP which then sends a RequestReportBCSM event to the SSP.
     When the Spirits server receives an event EDP-N, it then notifies
     the IP host. With EDP-Rs, the Spirits server can order re-routing 
     of the call, and order IN-related processing of the call.
     
     Subscribe <Event> <Mode> <Parameters>
                        Mode can be:
                         Dynamic request (EDP-R)
                         Dynamic notify (EDP-N)
                         Static (TDP-R)
               Event is any DP.
    
     Call disposition: S->P Accept call
                       S->P Reject call, Cause
                       S->P Redirect call, Redirect destination.

     Question: What does this really give us, since the service has 
     to still know the PSTN information. Why not route the IN parameters 
     to the Spirits server directly? Otherwise, a better way would be to
     make services network agnostic. 
     
     Answer: The service is invoked by something happening in the PSTN.
     This is a given for the Spirits WG. Read from the charter. Charter
     includes the words "building services to interwork with the PSTN".
     
     Chair: Lets stick with the charter.

     Issue: PINT has direct interfaces to the PSTN Gateway. It is similar
     with the A interface.
     how the Spirits message content is "something more" than just
     plain IN.

     Issue: Questions concerning notifications, static and dynamic 
     triggering. Trigger management and data management.
     Event reporting only can be limiting. CS-3 is much more broader.
     Answer: So far our discussions have been based on IN CS-2,
     but yes, we should consider CS-3 moving forward. 

     Issue: Relationship between interfaces B and C. Spirits Proxy 
     is more than a proxy since it is doing protocol conversion - 
     between B and C. Is C a combination of both PINT and Spirits protocols?
     (A and B are integrated into C?) Is there an interface between
     the PINT server and the Spirits proxy?

     Answer: There is no need for protocol conversion SIP may be used here. 

     Due to the time limitations the discussion was moved to the mailing list.

 5. Building blocks and why they matter, Lawrence Conroy.
    Issue: Architecture covers "who communicates", other drafts 
    consider "what information does the sender know".
    There seems to be no information on what message recipients 
      actually do with received events.

    Building blocks were described Very roughly (work in progress):

      Server/Service registration
      Service request processing relationships
      PINT/Spirits service monitoring.
      Call Leg Manipulation "service requests"
      Special resource functions (Data collection, ...)
  
      Registration, Relationships.
      What can be done, who can do it? server and service registration.
      Request/processing relationships: stateful or stateless nature
      of the processing. (multi-phase commit etc.,)
     
      Monitoring: in PINT, we use Subscribe/Notify/Unsubscribe. There is a 
      need to have the same in Spirits.

      Service Call Leg Manipulation:
      e.g. click to dial. add/drop/join/break legs, primitives for 
      this would facilitate conference services hold/resume/transfer,
      etc.

      Issue: Spirits must be as close as possible to a PINT system
      in terms of concept. There is a need for "service context" 
      to refer to previous requests made so there is a "create initial call"
      request as well.
   
      Special Resource/Data Actions:
      There's a need to collect information to tell the caller what's
      happening (via Specialized Resources such as Intelligent Peripherals).
      PINT could use this. e.g. an IP service may request a call to be made 
      to a party in the PSTN to collect info, and the call ends. Spirits could use this to         collect data from Internet users.

 6. Spirits Protocol Requirements, Jorgen Bjorkner.
     "How to add Internet Services to Telephony."
     
      Issue: Spirits services could be used by other voice networks.
      Voip services could be easily adjusted to be able to serve
      PSTN networks.
      Let us avoid profiles and flavors that do not exist on the Internet.
      There are no trust relations between PSTN operators and Spirits Service 
      Providers.
     The focus of this talk is on how to execute Spirits services.
     Subscription - call customer rep, or http request, IVR  etc.,
     Described basic Spirits services. Some services may require user
       interaction.

     Protocol Mapping proposal: Map events from the voice network into SIP.
     Solution: have the two parties involved in the phone call represented 
     as two SIP user agents in the Spirits client, and have the Spirits proxy 
     see these two parties as simple SIP phones (abstracting away PSTN 
     interfaces as far as the Spirits Proxy is concerned). 

     Chair: We may or may not use SIP, but this is not something we can
     decide right now.

     Issue: Subscription originates in the IP side, but that would be 
     PINT. (Jorgen agreed).

     Issue: SS7 has nothing to do with either Spirits or PINT.

     Issue: Is wireless IN able to provide all the information required 
     for events like "position changed" etc.?
     WIN and CAMEL standards do exist and could be used. We need a more
     generic means of carrying information into the Internet. We cannot 
     afford to be too specific, so we are not limited to flavors.

     Answer: we are not using INAP, we're just using information that is
     available at the SCP. We use a Spirits protocol to merely carry this 
     information. 
     Chair: We do not need to study the how, let's just stick to "whether 
     this information is available".  

     Issue: Proposal to use standard SIP services in the SIP network 
     for Spirits. 
     Chair: WG has not decided in the use of SIP yet. 

     Henry Sinnreich: talked about the contribution. This is the 
       exact opposite of Voip, its is "IP over Voice". This does 
       everything SIP does, but without SDP.

     Chair's concluding comments:
     
     Architecture there seems to be pretty well done. Requirements
     draft needs some work by the next meeting. Let us try to get a 
     design team or "team of experts" to get this done. 
     Please let us know who's interested in this work going forward.

Meeting is adjourn.