Subject: RE: [SPIRITS] Minor modifications to Joined PINT-SPIRITS architec ture

From: "Buller, Jeremy" <[email-masked]>
Date: Wed, 5 Jul 2000 16:38:45 -0400

Hello Alec, Igor

I must say, this is a most interesting thread :) but I am not 
sure if we're talking at crossed purposes here, or, there is 
an underlying difference of opinion?

> Well, it is a switch that is a voice handling thing, but for 
> the purposes of PINT and SPIRITS we are dealing with the 
> service control. 
Exactly! But surely in an abstract sense? With reference
to Jorge Gato's previous mail and Alec's mail agreeing 
there is a difference between implementation terminology 
in the US and Europe, if one doesn't abstract away from 
the working terms of the PSTN/IN domain it causes 
confusion. Agreeing to use any standard in the PSTN domain 
IMO doesn't help much.

> So, of course one needs to look at voice, and--for that 
> matter--the soft switch, but those are subjects of other 
> IETF WGs, ITU-T, and other bodies.
So according to Alec's mail an agreement has been made to 
focus on ITU-T INAP in the PSTN/IN domain? Looks like the 
applicability of this interface protocol may be getting 
smaller and require mapping.

> This would only affect
> > interface D, which is an implementation issue of one of the 
> >interfaces of the SPIRITS client.
> 
> Right. But note that this interface is to the service control.
So do you think we should defining this or not? My personal 
opinion is that I don't believe we should be, thereby following 
the PINT paradigm. References to what happens prior to the edge 
of the SPIRITS client IMHO should be only in the most abstract 
sense e.g. X or Y happens in *very* ambiguous terms. 

Anything else and IMHO we'd just end up going round and round 
discussing PSTN/IN service control and not (to me, the more 
preferable case of) the protocol itself i.e. :

  Something happens in the PSTN/IN/whatever which results in 
  a need for 'something' to be done in the Internet domain.
  (not really interesting in its detail)

  A message is sent that conforms to the SPIRITS protocol.
  (interesting)

I don't know, according to the charter there was supposed to 
be a drafted protocol by the end of this month, but we're 
only just getting an architecture tied down, still discussing 
the boundaries of consideration and the basis (if any) of a 
protocol itself (to SIP or not to SIP :)

So, I'll be the first to make the jump into the dark water 
and accept that either of you or Steve, or all of you will 
slap my wrist for presumption with regard to the basis of 
the protocol. However, I hope it elicits some comments and 
starts some discussion. Igor, Alec, Steve, I accept we need 
a vote on a potential basis for this protocol, but please 
feel free to just consider the actions first and ignore the 
SIP references. 

Below is an initial stab at a list of things or classes of 
things I'd've expected to see in a SPIRITS protocol with 
reference to possible SIP implementation methods:

(Apologies if some of this seems pointless or doesn't make 
sense, but I'm writing it off the top of my head)

Note! I do not distinguish in this list what exactly is in 
the PSTN. Neither do I specify what is in the Internet domain
it may be specialised server or even the subscribers own SIP 
phone.

  1) Registrations/Deregistrations of an Internet entity 
     to the PSTN entity (getting trusted entities 'known' 
     to the PSTN entity) SIP REGISTER - Not sure if the 
     reverse case is also required, it depends who you 
     think should be the controlling entity in the 
     SPIRITS case. Maybe this mechanism could be added to 
     the PINT side of the equation if required. It's a 
     point for further discussion.

  2) Registration of available services in the Internet 
     domain - SIP REGISTER again the same point as above
     about a reverse mechanism perhaps in PINT also 
     applies here.

  3) Tranferring control to an Internet Entity - SIP INVITE.

  4) Tear down a call which has (as in 3) Internet domain 
     involvement (returning control to the PSTN entity) 
     - SIP BYE.

  5) Continue call. The Internet entity has finished doing 
     whatever it was doing and returns control back to the 
     PSTN entity - SIP BYE to terminate involvement - the 
     PSTN entity may continue processing the call. 
     Alternatively, SIP TRANSFER to maintain a monitoring 
     relationship.

  6) Request/add a VoIP call leg - SIP INVITE

  7) Delete a VoIP call leg - SIP BYE

  8) Connect 2 or more call legs - SIP INVITE 
     
  9) Transfer call leg - use of SIP Redirction/ Proxy 
     mechanisms or TRANSFER method or BYE/ALSO method.

 10) Hold/resume VoIP call leg SIP INVITE(c=0.0.0.0) 
     then reINVITE.

 11) Event Notification - PINT like S[]bscribe/Notify 
     or SIP INFO method.

 12) Output tones/announcements - SIP 183 Session 
     Progress or INVITE to some IVR box. 

 13) Digit collection SIP INVITE to a device or SIP 
     INFO (depends on where collection entity is 
     considered to be).

 14) Setting service data in the Internet domain from 
     the PSTN - SIP INVITE or REGISTER.

 15) DP activation notification to Internet entity.
     SIP INFO or part of PINT like S[]BSCRIBE/NOTIFY.
     This would just be a generic mechanism for all
     such notifications. The service logic should 
     decide what to do with it/ if its relevant. 
     Otherwise, if you need to specify a message 
     format for each DP and thereby you 1) tie 
     yourself to a particular mechanism/terminology, 
     and, 2) Place more explicit handling requirements 
     on either end of the interface.

There are others, and I haven't even covered the extended 
PINT possibilities for doing things like setting DPs changing
PICs etc, but I'm guessing this list is probably contentious 
enough for starters.

Please feel free to ignore, add or discard any of the above 
list or indeed this entire email. I'm just trying fire-up a 
more detailed discussion.

I don't know, maybe in the long run this group will end 
up producing a list of Informational RFCs defining how 
these mechanisms can be used to do what this group is 
trying to do, time will tell.

Kind regards,

Jim Buller

--------------------------------
 Unisphere Solutions,
 900 Broken Sound Parkway, B12S
 Boca Raton, FL 33487. USA

 (+)1 561 923 3132
--------------------------------

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

---

From: Alec Brusilovsky <[email-masked]>
Date: Wed, 05 Jul 2000 16:05:12 -0500

"Buller, Jeremy" wrote:

> ...
> focus on ITU-T INAP in the PSTN/IN domain?

Jim, according to our charter:
"...[SPIRITS] services supported by IP network entities can be started
from IN (Intelligent Network) requests, as well as the protocol
arrangements through which PSTN (Public Switched Telephone Network) can
request actions to be carried out in the IP network in response to
events (IN Triggers) occurring within the PSTN/IN. ...Definition of any
information or data within the PSTN is the responsibility of the ITU-T
and so is out of scope for SPIRITS."
That is why we deal with ITU-T INAP. To date an official liaison from
SPIRITS to ITU-T SG11 was established (Hui-Lan Lu). I am copying Hui-Lan
on this message. She might be able to shed more light on SPIRITS-SG11
relations.

> ...

> ...

We just need to start with the Requirements and then select Protocol,
whether it will be SIP or not.

> feel free to just consider the actions first and ignore the

These are good ideas. Jim, could you convert these thought into an I-D
and publish it before 7/14?

Regards,
Alec

---

From: [email-masked]
Date: Wed, 05 Jul 2000 19:23:09 -0400

"Buller, Jeremy" wrote:
> Exactly! But surely in an abstract sense?

No, no--in the most direct sense. Please see the charter. We have already spent
enough time discussing that in two BOFs and the previous meeting, so I am afraid
I have nothing to add. I think we ought to move with the real work (to which
Jeremy has good proposals in his message) in support of the charter, and this is
what I am doing right now. Any conversation about IP telephony or soft switches
on this list will take away from the focussed, productive work.

> With reference

Jorge made a very specific statement, which, in my opinion, is in full agreement
with the decision that has been made in SPIRITS. The only international standard
on IN is the ITU-T standard. It has already taken care of the regional
differences. But, incidentally, in the requirements we are working on, we are
referring to the IMT 2000 call model so as to capture WIN, too.

> smaller and require mapping.

Not only the agreement has been made, but SPIRITS has started to work with ITU-T
on that; we have a liaison both ways. I don't know about the "applicability
getting smaller," but the only way to find that out is to examine this
applicability. I so far have not seen a single indication that would show that
INAP information is insufficient. 
> sense e.g. X or Y happens in *very* ambiguous terms.

On this point, I completely agree with Jeremy: we should not define this
interface. We are making this statement in the requirements.
 
> protocol itself (to SIP or not to SIP :)

I can see that all implementations have ALREADY been using SIP, so the issue of
selecting a protocol is moot as far as I am concerned. But the job right now is
to get the architecture and requirements, and that is what we are doing, and
this is how this thread was initiated.

> 
> ... Igor, Alec, Steve, I accept we need

Ah, it is very kind of Jeremy to associate my name with those of the esteemed
chairmen, but I am not one of them so it is really Steve and Alec who should
respond. As far as I know there is no vote in the IETF... But I think the moment
the requirements are ready, and we agree with them, the choice of the protocol
will be natural.
>      point for further discussion.

Yes, we have already captured that in the requirements (naturally, without
mentioning SIP--we ought to play by the rules). This, incidentally, is a PINT
X.0 service.

>      about a reverse mechanism perhaps in PINT also

An interesting issue--we ought to discuss that on line and, possibly, at the
meeting. I never thought about that.

>   3) Tranferring control to an Internet Entity - SIP INVITE.

Well, here Jeremy is a bit too blunt about SIP again... But then is INVITE
really a transfer of control? 

>      involvement (returning control to the PSTN entity)

I am more and more disagreing with "control." I think the situation is more
complex than either PSTN or Internet having "control" totally. It is more of
cooperation, in every single scenario. Look at ICW. While the end-user is making
decision on the disposition of the call, the PSTN is actively involved in
maintaining the call: the announcements are played to the calling party, SCP
sends REFRESH messages to the switch to reset timers. While I perfectly
subecribe to the notion that all these are to be invisible to the IP side, they
are quite visible to the engineers who must make the thing work.

>      Alternatively, SIP TRANSFER to maintain a monitoring

Ditto.

>  10) Hold/resume VoIP call leg SIP INVITE(c=0.0.0.0)

Those features have been proposed as PINT building blocks; by themselves, they
are not notification, which are supposed to be bread and butter of SPIRITS.

>  11) Event Notification - PINT like S[]bscribe/Notify

Ah! Here you are. That we have been writing about.

>      INFO (depends on where collection entity is

These two I am not sure about. The way we should define these features, in my
opinion, is so that the same protocol will apply to IN (where SCP and
Intelligent Peripheral do the job) and the VoIP scenario described above. I
asked a similar question at the last meeting (because , and Steve said we may
not concentrate on IP telephony specifically in SPIRITS.
>      on either end of the interface.

This is precisely what we have been tackling. I wish you joined us on this I-D,
but we really ought to send it to the IETF now. I hope you will join us for the
next issue--as always you have much to contribute.

> PICs etc, but I'm guessing this list is probably contentious

No, it is not contentious. It is interesting and useful, although a bit too...
blunt.  We will have an interesting discussion at the SPIRITS meeting! And I
hope you will place all the PINT-related proposals in an I-D to PINT--there you
can speak about SIP!

> more detailed discussion.

I for one thing cannot ignore it--if I did, that would amound to admitting my
own ignorance! There are too many good thoughts and useful and relevant
suggestions. 

Igor

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 6 Jul 2000 16:37:10 +0100

(Really, this concerns building blocks and Archies)
Hi folks,
  I think that "Jim's list" and Igor's comments are not mutually exclusive.

Whilst one might argue about using SIP or Some Other Protocol as the
"carrier" of state information between entities, the *intent* of an
invocation is what Jim's talking about, whilst Igor has been focusing
on is the information available in the Initiative System (*great* name!)
that in turn defines what information can be passed from the SPIRITS
client to the SPIRITS server as parameters of the invocation.
These don't really conflict, they're either end of the same pipe.

Re. Igor's suggestion that some of the building blocks should be put
into a PINT I-D whilst (as Alec suggests) the others should be put into
a SPIRITS I-D::
Hmm...we could do that, of course. As long as they are classified as
PINT ("invocation down") or SPIRITS ("invocation up") then the list
seems to be useful to *both* WGs, so instead I suggest that we keep
the two sets in one document, if that's OK.

Re. The disparate architecture diagrams:
A lot of Jim's comments on the PINT/SPIRITS architecture have been that
SPIRITS is a mirror image of PINT, from an architectural perspective.
The diagrams in his latest I-D show exactly how much they are reflections
of one another. The picture that we've seen from the SPIRITS architecture
draft seems to be more specific; I suggest that the SPIRITS/PINT diagram
that Jim produced is merely an abstraction of this (albeit rotated by 90
degrees :). Can't this be incorporated into the SPIRITS architecture draft
- and if not, then why not?

Am I being "brushed by a bus" again? Comments welcome.
-- 
All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd pay me for them"    |
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---

From: Alec Brusilovsky <[email-masked]>
Date: Thu, 06 Jul 2000 11:39:41 -0500

> These don't really conflict, they're either end of the same pipe.

Totally agree! Aside from using/not using SIP, (actually Jim and Igor agreed
even on that) both of them are focusing on the same invocation process.

Regards,
Alec