Subject: Re: PIN BOF

From: [email-masked] (Igor Faynberg)
Date: Wed, 31 Mar 1999 22:13:54 -0500

Scott Petrack wrote:

>
>As far as I know, IN triggers are truly requests for notification -- they
>must be "armed" in order to be active. So the process of triggering begins
>when an SCP sends a request to arm a trigger. It would be far too slow to
>have an SCP listening in on a port for every single call attempt and then
>decide what to do.
>

I apologize for contributing to confusion; I should really have said more.
The IN triggers are actually in the switches. Triggers per se are static
(they are set by the service management system). But the same detection
points in the call model (again, within the switches!) that can be set
"off-line" as triggers can also be set "on line"--for the duration of a call
and only for that call--by the SCP by using the procedure that Scott described 
absolutely correctly.

To summarize: triggers are set statically for all calls WITHOUT any SCP
action; Notifications are requested by the SCP for the duration of a call
by the SCP sending message to the switch.  Note that in the case of a
trigger, it is the switch that initiates the transaction by sending
a query (request) to the SCP, which is to respond. 

Now, neither PIN nor PINT has anything to do with the switches--those
are shielded from the IP servers by the SCP (stictly speaking, SCF, but
this is not essential for the discussion, so I will stick to the "SCP"
term.) But the taxonomy of messages is parallel to what is happening
between a switch and an SCP, and I wanted to exploit this parallelism as
I believe it will clearly outline the difference between the two sets
of services:

In PINT, the services start by the PINT Client issuing the request (INVITE)
to the SCP. (Well, maybe, I should really speak about PINT client doing that
to PINT Server, which then does same to the SCP, but for the sake of
the discussion I consider them co-located.

So, here is the picture (and its parallel in the IN. Faint-hearted and
the haters of PSTN, please DO NOT look at the right-hand side! It is for
illustration only, anyway.):

PINT Client --- INVITE--->  PINT Server/SCP           SCP -- [Magic] -> Switch

Notifications work here as the mirror image of the PSTN (as they should!):

PINT Client       PINT Server/SCP     SCP                   Switch

---- Request for Not. -->               --- Temporarily arm DP ->

<---Notification--------                <----- Notification ----

Note that in the PINT services, no IN triggers are involved. Everything
is clear and square.

In PIN (I am talking about the ICW, which has been described in Alec's
draft and the call notification, as presented by Lev at the PIN BOF, 
but this also applies to most services Lawrence and I proposed yesterday),
things work like that:

(I am placing the PSTN at the left-hand side now)

Switch -- Query --> SCP        SCP/PIN Client -- INVITE --> PIN Server

The query on the left-hand side, is TRIGGERED by a trigger, which was
set by service management. For example, in the case of ICW, the trigger
would be the "called party busy" DP in the call model. And in the case,
of the Internet side, the client and server (even though sharing the same
SIP-based architecture with PINT) have exchanged their roles.  

Should the PIN Client sit and listen for everything? No. The process for
the client should be created by the SCP in this case. But, as Scott
asked, shoult the SCP listen for everything. Well, yes, this is the SCP
job. (Technically, the switch's INAP query is carried by the TC-BEGIN,
which starts the transaction and results in runnic a specific service
logic program, but this is a strictly parenthetical remark.)

I believe this clarification makes all parts of the existing input into
the PIN activity (Alec's ICW draft, Lev's presentation, and Mr. Buller's
PIN-related SAINT draft) consistent with each other. I also hope that
it responded to Scott's question.  If not, nothing could warrant my sending
such a long message...

Igor

---------
This message came from the IETF PINT Working Group Mailing List.