Subject: Re: FW: Re: Meeting Notes V3

From: Alec Brusilovsky <[email-masked]>
Date: Wed, 05 Jan 2000 14:02:12 -0600

Lev, Igor,

Thank you for responding and clarifying this issue. 
Regretfully, due to the family matters, I was unable to respond earlier.

Holiday Greetings and let us all be good spirited this millennium,
Alec

"Slutsman, Lev A, ALSVC" wrote:
> 
>             I am completely agree with Igor's comments. Let me just ass my
> own spin to some  Q&A.:
> > >> Q: Most services seem to be built from a small set of blocks. Do we
>         >> want
>         >> to start from a service such as ICW?
> A: Our output is suppose to be an Internet protocol suitable for SPIRIT type
> of services. In order to outline the protocol  and architecture requirements
> , we have selected three representative (in our opinion) services.
> 
> >>Q:Could anyone elaborate what "blocks" really are? Are they similar to
> service
>         >independent building blocks (SIBs) in the IN terminology?
>         A: Since our goal is  the SPIRIT protocol rather than service
> creation environment, SIB is out of question. We taking about protocol
> building blocks.
> 
>         Best regards, Lev.
> > -----Original Message-----
> > From: [email-masked] [SMTP:[email-masked]]
> > Sent: Friday, December 17, 1999 7:24 PM
> > To:   [email-masked]; [email-masked]
> > Subject:      Re: FW: Re: Meeting Notes V3
> >
> >
> > Naoto MAKINAE wrote:
> >
> >
> > > I wish I could have attended the kick-off meeting.
> >
> > Actually, the decisions in the IETF are made only on mailing lists, so
> > there
> > is a chance to make up for one's absence.
> >
> > >>Here are some comments and questions.
> > >
> > >> Question: Most services seem to be built from a small set of blocks. Do
> > we
>         >> want
>         >> to start from a service such as ICW?
> 
> > >> Answer: ICW is one of three examples of SPIRITS services that we
> > >> have in our
> > >> charter. WG is studying blocks that allow to construct example
> > services.
> > >
> > >Could anyone elaborate what "blocks" really are? Are they similar to
> > service
> > >independent building blocks (SIBs) in the IN terminology?
> >
> > No, by no means SIBs. The "blocks" here are NOT meant to be API or model
> > API. We discussed much of that during the BOF; as far as I understand the
> > use
> > of the word "blocks" here is a specification of a set of messages,
> > possibly
> > augmented by behavioral (i.e., sequencing) description, which can be used
> > for
> > a broad range of services.
> >
> > >
> > >> Issue: Existing service logic must not be broken by what we put into
> > the
> > >> Internet. Real-time interactions between the Internet and PSTN will
> > >> require that we interwork with SG-11 since all timers and other
> > mechanisms
> > >> must
> > >> interwork seamlessly.
> > >
> > >What sort of concern is behind the issue? IMHO, the WG's effort will be
> > >confined to the interworking of PSTN/IN and IP, and hence will not break
> > >the existing IN specifications. Or are you saying that pre-SPIRITS
> > >implementations should not be made a sort of obsolete by the WG's work?
> > >
> >
> > The chairmen (who issued the report) should correct me if I am wrong. I
> > interpreted this statement in exactly same way as Naoto did in his last
> > sentence. This, as I recall, was the resolution of the meeting.
> >
> > ...
> >
> > >... The WG should not exclude the possibility of interfacing with
> > >softswitches, call agents, gatekeepers, or SIP servers.
> > >
> > >The physical architecture expressed in
> > >draft-faynberg-spirits-protocol-00.txt
> > >implicitly excludes the possibility stated above, so the WG will need a
> > new
> > >one ...
> >
> > I disagree. The figure reflects what has been specfied in the charter.
> > SPIRITS server interconnects with the PSTN via the IN (i.e., service
> > control
> > function).
> >
> > >... Interfacing
> > >entities in the
> > >telephone network might be service control points, service nodes,
> > >softswtiches, call agents,
> > >gatekeepers, or SIP servers, but the interface B (see below) must be the
> > >same regardless of
> > >the interfacing entity in the telephone network.
> >
> > Only service control points and service nodes (which have the
> > service control function)--but not switches, for example--are to be
> > connected to
> > a SPIRITS server.
> >
> > But that does not mean that a soft switch cannot be supported.
> > The whole idea of the soft switch is that it behaves to the PSTN as though
> > it is a "normal" switch. Thus, a soft switch uses ISUP to talk to normal
> > switches and it uses INAP to talk to SCPs. (This is where SIGTRAN comes to
> > the
> > rescue.) Similarly, a soft switch can get to the SN via Q.931+ interface.
> > The soft switch needs to connect to SCP, to begin with (so
> > as to get access to the existing IN-supported services). Thus, whatever a
> > normal switch can communicate to the SPIRITS server via SCP, the soft
> > switch can too, and in exactly the same way.
> >
> > Overall, connections to the IP telephony entities are strictly implicit in
> >
> > SPIRITS.
> >
> > >
> > >The WG should also not preclude the possibility of open APIs around the
> > >interface B at this point.
> > >
> >
> > Actually, no WG may preclude that. The issue is really whether a WG is
> > planning to work on it. I don't think SPIRITS does, and to the best of my
> > knowledge, IETF is not dealing with APIs. As far as I can remember,
> > SPIRITS
> > chairmen have made a similar determination concerning SPIRITs. W3C would
> > be a
> > right place to deal with the API. I think Alec and Steve have actually
> > written
> > that somewhere in the report.
> >
> > With best wishes for the holiday,
> >
> > Igor
> >