Subject: Problem with bell-labs SMTP server

From: Scott Petrack <[email-masked]>
Date: Sun, 4 Apr 1999 23:07:49 -0400 (EDT)

I just got mail from bell-labs saying that mail sent directly from an SMTP
server on a dial-up link will be blocked. If this is true, then the
following mail was not sent to the pint list.

According to the mail I received, this policy has been in place for
several *weeks* now, which means that many letters of mine to people in
bell-labs may have been silently deleted. 

I will now resend a few letters I sent today before I received this
unpleasant letter. But previous mail is likely to be lost. 

If you rely on the bell-labs.com server to receive mail from and have not
received something you expect, please let me know. 

Scott

---------- Forwarded message ----------
Date: Sun, 4 Apr 1999 20:15:23 -0400 (EDT)
From: Scott Petrack <[email-masked]>
To: Igor Faynberg <[email-masked]>
Cc: Alec Brusilovsky <[email-masked]>,
     pint list <[email-masked]>,
     Jonathan Rosenberg <[email-masked]>,
     "Buller, Jim" <[email-masked]>,
     "[email-masked]'"
    <[email-masked]>
Subject: Re: PIN BOF

Thanks Igor for this very useful posting. But I am going to annoy you as
usual, I'm afraid:

You are of course correct that triggers are often set by the management
system, rather than by the SCPs themselves. I was being a bit too fast
before -- to spell it out, my understanding is that the management system
sets a trigger like "notify SCP xxxx whenever a call attempt to subscriber
yyyy comes in." When that notification reaches the SCP, then the SCP can
install a per-call notification, such as "I want to receive notification 
about every ring that goes by on this call attempt you just told me
about."

So my point is that in either case, the sending of notification was
preceeded by some explicit REQUEST that the notification be sent under
certain conditions. 

Whether the request comes from the same entity that actually receives the
notification is a technical detail (of course an important one for
scaleability, etc.) Whether the request is for a "static" notification
(i.e. independent of any particular call) or "dynamic" notification (i.e.
for the one call only), is also a technical detail (equally important, of
course). 

What is important is that in all of these scenarios there is some REQUEST
for notification that comes in, and this request somehow "knows about" and
indeed "designates" the entity which is to receive the request, should it
ever come.

This is very different than what happens in, say, a Mail server, or a Web
server. These are servers that just sit around all day waiting for random
requests to come in. They advertise themselves via various directory
services, but the things that send them requests were never ever requested
to do so by any protocol element.

In the end, we can always blur the lines between the two things. For
example, we could say that an invitation-only-mailing-list is sort of like
the subscribe/notify model, where you have to receive a "request" (i.e.
"invitation to the mailing list") in order to post to it. But this doesn't
alter the basic fact that the protocol model involved in this case is one
with a server listening to all comers, without any prior "request" or
"subscription" within the protocol.

I learned a lot from your post, and I really thank you for it. But it
convinced me further that the "trigger" thingie you need/want is really
another example of the basic subscribe/notify model.

The two requirements I learned from your post are:
	a) it must be possible that that the host which requests the
notification be different than the host which will (eventually) receive
the notification. (So that the management system can ask the switch (SCF
really) for notification to be sent to the SCP later)
	b) it must be possible to request a notification on a per-call
basis and without reference to any particular call.

Of course, there are many things lacking, like how to describe the
triggers themselves. 

Scott

On Wed, 31 Mar 1999, Igor Faynberg wrote:

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