Subject: Re: FW: Re: Meeting Notes V3

From: [email-masked]
Date: Fri, 17 Dec 1999 19:23:43 -0500

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

---

From: "Naoto MAKINAE" <[email-masked]>
Date: Mon, 20 Dec 1999 18:13:54 +0900

Dear all

I appreciate your response, Igor.

> a broad range of services.

A "block" is a set of SPIRITS messages. Of course, the SPIRITS protocol will
consist of several message sets.

> sentence. This, as I recall, was the resolution of the meeting.

I would like to hear other opinions, if any.

> SPIRITS server interconnects with the PSTN via the IN (i.e.,

I do not pick holes in your document, Igor. So, please do not be offended.

What I am saying is that:

(1) The WG should not exclude the possibility of interfacing with
softswitches, call agents, gatekeepers, or SIP servers.

(2) People might misunderstand that the working group does not support
softswitches, call agents, and others because there are service control
points and service nodes, but no softswitches, call agents, nor others
in the document.

(3) To avoid the misunderstanding stated in (2), we could put softswitches
and ohters into the physical architecture. But this would not be a
consensus,
because the opinion stated in (1) is supposed to be debated in the mailing
list. So, I would rather not define the inside of telephone network for a
while. Service control points, and service nodes are definitely in the
telephone network. But, softswitches and others may or may not be in the
telephone network. How about the figure in my previous letter?

> switch can too, and in exactly the same way.

A "softswitch" is one of the most popular buzzwords, and sometimes makes
confusion. As Steve and Alec wrote in the meeting report, we need agreement
in terminology.

I do not think a softswitch is required to connect to SCP. To my
understanding,
a softswitch can contorl media gateways,
a softswitch can acts as a gatekeeper and a SIP server,
and, a  softswitch can act as a SPIRITS server too.

Igor and I must have somewhat different definitions for a softswitch.
Certainly we
need agreement.

> right place to deal with the API.

I should have been more specific.

Some APIs, for example Parlay API,  involve communication protocols.
My feeling is that those APIs and the working group have something in
common,
and there would be some conflict.

Best regards,

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