Subject: FW: Re: Meeting Notes V3

From: "Naoto MAKINAE" <[email-masked]>
Date: Fri, 17 Dec 1999 12:36:23 +0900

To all SPIRITS members

I wish I could have attended the kick-off meeting.

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?

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

> Issue:
> In the PSTN/IN specifications each parameter defined and is always well
> explained with examples of use. It is difficult to state the exact role of
> IP-based SPIRITS elements in every case (may be SCF, or other functions).

I agree. It is always difficult to produce clear specifications. We should
work hard. But we must not cling to perfection, which is unattainable.

> Question: SPIRITS might end-up with VoIP legs in calls. Should we preclude
> VoIP
> scenarios in SPIRITS.
> Answer: SPIRITS will neither include nor exclude this explicitly. However,
> we
> are mainly interested in a signaling and control protocol.

<<snip>>

> Question: Can we look at supporting an interface to the
> softswitch, generic
> term
> for Call Agent, Gatekeeper, etc?
> Answer: This will be discussed on the mailing lists. It will become very
> clear
> by April.

I agree. 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 do not
believe that the anatomy of telephone network is necessary. 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.

The WG should also not preclude the possibility of open APIs around the
interface B at this point.

+-----------+     +---------+     +----------+
|           |  B  |         |  A  |          |
| Telephone |-----| SPIRITS |-----| Terminal |
| Network   |     | Server  |     |          |
+-----------+     +---------+     +----------+

Regards

naoto
--
Naoto MAKINAE
Intelligent Network Project
Information Sharing Platform Laboratories
Nippon Telegram and Telephone Corporation
Email:[email-masked]
Phone:+81-422-59-4167
Fax:+81-422-37-7441

---

From: "Slutsman, Lev A, ALSVC" <[email-masked]>
Date: Tue, 21 Dec 1999 11:22:59 -0500

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
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:
> 
> 
> Actually, the decisions in the IETF are made only on mailing lists, so
> there
> is a chance to make up for one's absence.
> 

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