Subject: [SPIRITS] On Joint PINT/SPIRITS Architecture

From: [email-masked]
Date: Thu, 29 Jun 2000 22:04:41 -0400

To all in good SPIRITS:

Following up on the architecture discussion led by Lev in Adelaide and,
particularly, on the request from the chairmen ("esteemed chairmen!"--as
Lawrence would immediately correct me) to produce the protocol requirements for
the IN and PINT points of view, respectively,

I have tweaked a bit the original architectural picture so as to juxtapose PINT
and SPIRITS and try to fit them within the same framework. It appeared to come
fairly naturally while reviewing the pre-SPIRITS implementations report. Much
inspiration for what I did came from  Sung-Yurn Rhim's and Jinkyung Hwang's
material (which explicitly mentions PINT), but I also see it immediately
consistent with what Shinji Ago, S. Moeenuddin, and S. Hadvani described (and
they explicitly mention SPIRITS). The OCC material also fits perfectly well
here. As for the rest, it is even easier to fit, I believe, because no specific
function (PINT or SPIRITS) has been identified in that architecture. 

So, in the picture below, only PINT Client is seating on the User's PC (or
appliance). The Interface A is what PINT has been doing (and what, in fact, has
been done for PINT 1.0). Now, both PINT Server and SPIRITS Client are connected
to the PSTN Service Control through the means outside of either PINT or SPIRITS
scope. 
The PINT Server and SPIRITS Server are colocated. (Again, this is consistent
with the existing implementations.) 

Now, this is an issue that we have never discussed, but I submit that the
interface between PINT Server and SPIRITS Servers are of no interest to us. (If
someone disagrees, I am ready to elaborate on this point). This leaves only one
interface, B, for the SPIRITS protocol (I am not addressing the SMS and
MIB-related 
issues). 

Hui-Lan and I are in the process of writing  the requirements for the relation
of actions on A and C, and Lev is working on the architecture, so this is an
important check-point. Does anyone see anything wrong with this?

Note that the only real change (comparing with the crude combination of SPIRITS
and PINT architecture) is the elimination of the SPIRITS element presence at the
end-user's appliance, but the PINT Client should be able to take care of
whatever is needed. One question to ask here, is HOW would the PINT Client be
invoked on executing the SPIRITS Server. 

Answering it, I understood why Christian Huitema and Lawrence Conroy have made
Service Subscription a high priority item. (They brought this item up twice at
the first and second SPIRITS BOF, and I remember no objection, nor did I object,
although I did not fully understood the importance of it until now.) So the
answer is that the PINT Client would need to explicitly subscribe or register
for SPIRITS service. This is an essential requirement, indeed, and it
significantly simplifies the architecture and cuts on the protocol effort.

Well, enough said. The picture follows.

With thanks for your attention,

Igor

                             ..................
|-----------|                .  |-----------| .     C         
|PINT Client| <---- A ------>.  |PINT Server| <------------> PSTN 
|-----------|                .  |-----------| .              Service
                             .      |         .              Control
                             . |---------|    .             D  ^
                             . | SPIRITS |    .          |-----|-----| 
                             . | Server  |  <---- B ---->|  SPIRITS 
|                                                                  .
|---------|    .          |   Client  |
                             ..................          |-----------|

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: "Naoto MAKINAE" <[email-masked]>
Date: Fri, 30 Jun 2000 12:34:44 +0900

Igor and All,

> To all in good SPIRITS:

<<snip>>

> with the existing implementations.)

I see some problems with the proposed picture:

 - The interface C, which connects a PINT server and PSTN/IN, is outside the
   scope of PINT. PINT does not specifiy the interface C.
 - A SPIRITS client may co-reside with PSTN/IN. The interface B and D are not
   necessarily distinct.
 - A PINT client is defined to be an "Internet host that sends requests for
   invocation of a PINT Service." Since a SPIRITS service such as ICW is
   not a PINT service, the PINT client is not supposed to support
   SPIRITS services. There must be another user PC that can communicate with the SPIRITS
   server and handle SPIRITS services. Or "PINT client" must be changed to a more
   generic term such as "User PC." I assume the latter would be better.

> interface between PINT Server and SPIRITS Servers are of no interest to us. (If

Agreed. The interface between PINT Server and SPIRITS Server is of no interest.

> interface, B, for the SPIRITS protocol (I am not addressing the SMS and

The interface A between PINT Client and PINT Server is defined in RFC2848
("The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone
Call Services"), and does not support SPIRITS services. The interface A needs
enhancement.

> important check-point. Does anyone see anything wrong with this?

Since "C" is between PINT Server and PSTN/IN, you are going to specify
the interface for the PINT services. Is it right?

> significantly simplifies the architecture and cuts on the protocol effort.

Agreed. Harmonization of PINT and SPIRITS would be beneficial.
Unification would be much better, if possible.

naoto

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

---

From: Jörgen Björkner <[email-masked]>
Date: Fri, 30 Jun 2000 11:02:10 +0200

Hi,
To allow for the user client (referred to as PINT client in Igor's mail) to
be able to deal with the event notifications generated from the Spirits
server must there probably be some extensions to PINT.
Therefore would it probably be appropriate to call this entity something
else, so people don't lock their mind's to certain functionality. Maybe will
we end up with something like PINT V2...
I am not sure that someone implementing a SPIRITS service wants to implement
everything described in the PINT RFC, but nothing prevents a SPIRITS user
agent (more neutral name, for the entity the user is having installed on his
device) to be co-located with a PINT client in a end users device (note that
I am not restricting it to be a computer to avoid a certain service focus).
I think that the new subscribe/notify extensions to SIP should be reviewed
if they could be used for this purpose.

Therefore might there be appropriate to define a SPIRITS extension to SIP,
which reuses the expertise and experiences from PINT. Otherwise would it be
need for an extension to PINT, since for example addition of hove to pass
back information to the SPRITS server has to be extended. For example an
event notifying a SPIRITS user agent that a call is being set up might want
let the user to redirect the call before instead of answering. This
information must be sent back to the SPIRITS server in either the SDP of a
200, or maybe more appropriate in a 302 moved temporarily.

I also think that the D interface is dependent of the voice network which
the SPIRITS server is connected to, and is an implementation issue, or a
question for those who is developing voice network standards (read ITU for
the PSTN case, 3GPP for 3G networks).

What do you think of the following comparison with SIP, the SPIRITS user
agent is similar to a SIP user agent, which will need some user feedback.
Some logic, acting on a users behalf, could be place in a SIP server, which
the user belongs to. In the SPIRITS case would this be the SPIRITS server.

Maybe I should take some time to write down my ideas in a draft?

/Jörgen
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: den 30 juni 2000 04:05
To: SPIRITS
Subject: [SPIRITS] On Joint PINT/SPIRITS Architecture

To all in good SPIRITS:

Following up on the architecture discussion led by Lev in Adelaide and,
particularly, on the request from the chairmen ("esteemed chairmen!"--as
Lawrence would immediately correct me) to produce the protocol requirements
for
the IN and PINT points of view, respectively,

I have tweaked a bit the original architectural picture so as to juxtapose
PINT
and SPIRITS and try to fit them within the same framework. It appeared to
come
fairly naturally while reviewing the pre-SPIRITS implementations report.
Much
inspiration for what I did came from  Sung-Yurn Rhim's and Jinkyung Hwang's
material (which explicitly mentions PINT), but I also see it immediately
consistent with what Shinji Ago, S. Moeenuddin, and S. Hadvani described
(and
they explicitly mention SPIRITS). The OCC material also fits perfectly well
here. As for the rest, it is even easier to fit, I believe, because no
specific
function (PINT or SPIRITS) has been identified in that architecture.

So, in the picture below, only PINT Client is seating on the User's PC (or
appliance). The Interface A is what PINT has been doing (and what, in fact,
has
been done for PINT 1.0). Now, both PINT Server and SPIRITS Client are
connected
to the PSTN Service Control through the means outside of either PINT or
SPIRITS
scope.
The PINT Server and SPIRITS Server are colocated. (Again, this is consistent
with the existing implementations.)

Now, this is an issue that we have never discussed, but I submit that the
interface between PINT Server and SPIRITS Servers are of no interest to us.
(If
someone disagrees, I am ready to elaborate on this point). This leaves only
one
interface, B, for the SPIRITS protocol (I am not addressing the SMS and
MIB-related
issues).

Hui-Lan and I are in the process of writing  the requirements for the
relation
of actions on A and C, and Lev is working on the architecture, so this is an
important check-point. Does anyone see anything wrong with this?

Note that the only real change (comparing with the crude combination of
SPIRITS
and PINT architecture) is the elimination of the SPIRITS element presence at
the
end-user's appliance, but the PINT Client should be able to take care of
whatever is needed. One question to ask here, is HOW would the PINT Client
be
invoked on executing the SPIRITS Server.

Answering it, I understood why Christian Huitema and Lawrence Conroy have
made
Service Subscription a high priority item. (They brought this item up twice
at
the first and second SPIRITS BOF, and I remember no objection, nor did I
object,
although I did not fully understood the importance of it until now.) So the
answer is that the PINT Client would need to explicitly subscribe or
register
for SPIRITS service. This is an essential requirement, indeed, and it
significantly simplifies the architecture and cuts on the protocol effort.

Igor

                             ..................

---

From: [email-masked]
Date: Fri, 30 Jun 2000 10:23:54 -0400

Naoto,

This was a quick and detailed response!  My replies are in-line, and I am happy
to observe that we seem to be in full agreement so far, as far as I can see. I
am very glad you are back!

Igor

>    scope of PINT. PINT does not specifiy the interface C.

Absolutely. I guess there was a misunderstanding? (I never said C was PINT's,
only A).

>  - A SPIRITS client may co-reside with PSTN/IN. The interface B and D are not

I think you mean C and D? If so, we are in absolute agreement again.
(Especially, regarding the point of SPIRITS client co-residing with Service
Control.)

>    SPIRITS services. 

Yes, that is true, and it is not PINT 1.0 that is being mentioned here. If
anything, it is the future PINT that is referred to. The idea of service
subscription has been brought up by Christian more than a year ago, and in
private discussions we thought this would be a new PINT service (or rather
building block). 

>There must be another user PC that can communicate with the SPIRITS

I would not argue with the terminology here. Yes, we can change it. But then we
will need to consider two interfaces in SPIRITS, and the issue of PINT/SPIRITS
interworking would become convoluted. For me, to whom the esteemed chairmen
entrusted the first shot at the PINT-to-SPIRITS interworking requirements, it is
much easier to get at this chicken-and-egg problem by dividing it into
independent pieces.

> > ...

> Call Services"), and does not support SPIRITS services. The interface A needs

Right. This is the future interface "A" I am talking about.

> the interface for the PINT services. Is it right?

I am afraid I did not understand this question. "C" is out of scope of the IETF
(and, I suspect, you would agree with me that PINT server should be co-located
with Service Control).

> Unification would be much better, if possible.

Well, PINT building blocks deal with what starts on the IP side, SPIRITS ones
with what starts at the PSTN side. Put together... This is why I attempted to
sort out things the way I did.

Respectfully,

Igor

---

From: Alec Brusilovsky <[email-masked]>
Date: Fri, 30 Jun 2000 09:47:37 -0500

Naoto MAKINAE wrote:
...

>  - A SPIRITS client may co-reside with PSTN/IN. The interface B and D are not

True. However, the resulting architecture is much cleaner this way - and more scalable.

> ...
> Harmonization of PINT and SPIRITS would be beneficial.

I see interworking with PINT as one of the SPIRITS requirements. A number of "real life"
services are possible only by combining PINT and SPIRITS building blocks. PINT is slightly
ahead of us. This means that we have to intensify our efforts.

Regards,
Alec

---

From: [email-masked]
Date: Fri, 30 Jun 2000 15:38:26 -0400

> we end up with something like PINT V2...

Yes, when the draft is out, we will make sure that is clear.

> everything described in the PINT RFC,

A good point. Based on the SPIRITS experience (and SPIRITS's charter is a great
improvement on the PINT one), the way to think about the PINT-work-to-be is
definining  mutually-independent buidling blocks, so that an implementor can mix
and match them.

>but nothing prevents a SPIRITS user
> device) to be co-located with a PINT client in a end users device 

Yes, but if we define that as an independent entity architecturally, we will
need one more protocol. I so far belive that we can avoid that, but may be we
cannot. This is precisely why I wanted to discuss it (and I am happy that the
discussion started).

> I am not restricting it to be a computer to avoid a certain service focus).

Precisely. We've been trying to call it a "PC or Internet appliance," following
Vint Cerf's recommendation.

> I think that the new s[...]be/notify extensions to SIP should be >reviewed

Yes, and we are putting this in the requirements.  S[..]BE/NOTIFY will play
central place in SPIRITS/PINT-to-be as the mechanism for setting DPs
dynamically. (Note: The Lucent OCC implementation has used tbe [vanilla] SIP
REGISTER method for the initial Client registration. But back then there was no
PINT standard. (We are implementing it now.)]
 
> 
> Therefore might there be appropriate to define a SPIRITS extension to >SIP,

This is precisely what we have been trying to address, although we try to be
abstract. (Remember, we have not decided what the protocol will be... We are
just producing requirements.

> the PSTN case, 3GPP for 3G networks).

100% agreed. (Incidentally, I am glad you mentioned Wireless; it is obvious now
that Wireless IN is a thing that will have to interwork with SPIRITS.)

> the user belongs to. In the SPIRITS case would this be the SPIRITS server.

I think you are mentioning the SIP/CPL thing? Sure! I am so happy I am not a
chair in this group so I can talk about things we are not supposed to be talking
about (yet)!

> Maybe I should take some time to write down my ideas in a draft?

I personally would very much like to read it. And this is the way to get the
work going!

Igor

---

From: Alec Brusilovsky <[email-masked]>
Date: Fri, 30 Jun 2000 16:16:10 -0500

Jörgen,

I knew that this discussion will get you going. Please see my comments inline.

Regards,
Alec

Jörgen Björkner wrote:
...

> I am not restricting it to be a computer to avoid a certain service focus).

Lev proposed to use "IP Host" terminology at some point.

> which reuses the expertise and experiences from PINT.

Jörgen, please wait.
Without requirements in place, we are not set on any particular protocol.
...

> the user belongs to. In the SPIRITS case would this be the SPIRITS server.

Please see my previous comment about requirements preceding protocol selection.

> Maybe I should take some time to write down my ideas in a draft?

Jörgen, that is a wonderful idea. After all, that is the best way to participate
in this WG's work.