Subject: Re: PIN BOF

From: Alec Brusilovsky <[email-masked]>
Date: Thu, 01 Apr 1999 08:14:01 -0500

Igor Faynberg wrote:

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

Thank you for a much needed clarification and for even more essential little
tutorial on IN.

-Alec

---

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

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

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

---

From: Scott Petrack <[email-masked]>
Date: Sun, 4 Apr 1999 21:44:22 -0400 (EDT)

Sorry for the following extremely long post.

Here is my take on the current situation vis-a-vis PIN:

1. The list of potential PIN services (note that some want to do these,
some want to exclude certain ones)
	Internet Call Waiting
	Internet Call Redirection
	Internet Call Forwarding
	
	Registration of Location/Availability
	Subscription to a particular service

Not all of these are very well defined, and it might be nice to get some
simply-worded service definitions (with
enough ambiguous generality so that everyone's variation can be covered
without endless nitpicking ;-)).

2. Building Blocks we pretty much have:
	SIP -- 	used to "set up" specified session with remote "user(s)"
		used to register that a "user" is available to receive 
			invitations at a specified "location."
		used to transport data to remote "user(s)" that may be
			moving around.
	SDP -- 	used to describe MBONE sessions
		extended by PINT to describe certain "PSTN sessions" 
		(aka telephone calls)
	PINT --	invitations to remote user(s) to setup specified "PSTN
		sessions." Since the PSTN phones themselves are not on the
		Internet, the PINT invitations are delivered to an IP host
		which acts on behalf of the remote phone user. Eventually,
		PINT may be extended to enable more general requests from
		one IP host to another to have the PSTN "do something."
	Subscribe/Notify methods -- used to request and then receive
		notification when "something happens". SIP has been
		suggested for this purpose for two main reasons:
		a) the request for notification sets up a "session-like"
		relationship between IP hosts
		b) the requestor or purveyor of the notification may well
		be moving around, and SIP is designed to transport data to
		hosts that may be moving around.
		MEGACO is also working on methods to request and receive 
		notification when certain switch events and signals occur.
		The MEGACO events are often lower-level than the PINT
		events, and there is an assumption that the two sides are
		not mobile.

3. What we don't have and some people think we need:
	a) a way to describe various PSTN "triggers". (Here, from what
I can tell, one might imagine a small core list of universal triggers,
although in today's PSTN each vendor and country has a separate list of
many many triggers, and there is no overlap beyond a very small core
	b) a standardized way to transport around these events, signals,
triggers. As mentioned above, the subscribe/motify model is being
developed in PINT and MEGACO. But many people on the PIN list seem to
think that this is not the right model for certain PIN services. (I have
not seen a convincing example, but maybe that's me).

<beginning of explicitly biased personal comment>
I myself am very skeptical that we will be able to do anything useful with
IN triggers, beyond what SIGTRAN might eventually do. On the other
hand, there is a
really important related need that we will eventually have to get to: how
to get notification about what is going on inside a SIP proxy server in
real-time, and maybe even control it. This is the "IETF equivalent" of
triggers. The difference between this and "IN triggers" is in the call
model. SIP presents a certain single call model. For better or worse, that
is the call model we are standardizing in the IETF. (Personally, I think
that it is for better). IN triggers are explicitly tied to other call
models that are different state machines. Hundreds of different state
machines, actually, depending on vendor and administration. So I
have no problem with SIGTRAN being used to transport actual IN messages
around, but I think that once we start looking *inside* the messages to
the semantics of the triggers, we will need to confine ourselves to the
SIP call model.
Personally, this seems like a good thing to me, because I think that the
SIP call model is rich enough to cover the basic IN triggers that everyone
needs to do. And it will avoid covering the tens (hundreds?) of other
triggers that experience has shown can not be standardized anyway.
<end of explicitly personal biased comment>

	c) We can't describe "arbitrary PSTN sessions" right now. We can
only describe some very simple ones (using the PINT extensions to SIP). 
	d) This means that we can't do PSTN third party call control.
(This is not a terrible emergency -- the PSTN can't really
do third party call control either in any interoperable generic way).
	e) a way to describe the actual sounds used to convey certain
"event", "trigger" and "signal" information (although yes I'm working on
it ;-)). I mention this here because it will be needed if we want to
reproduce things like the "call waiting experience" (G-d forbid).

4. What we really SHOULD NOT DO, and DO NOT NEED (more personal bias)

	I think that it would be a disaster to try to specify any actual
"service", like (say) an "internet call waiting service". I know that this
is hard to swallow for PSTN experts. And I know that every example I give
only convinces PSTN experts that indeed we need to specify every service
down to the last detail. But I give as evidence: the literally hundreds of
variants of "call transfer" that have been standardized. This is truly not
a productive use of time.

	The good news is that if we get our building blocks right, then
there are lots of interoperable toys that can be built. 

Conclusion: the thing I can see that we really lack is a way to ask a
SIP server to send some specified host notification of the receipt of some
SIP message, and maybe some way to install per-call CPL logic into that
server in real time. 

To do "Internet Call Waiting" and Internet Call Redirection we just need
to have some piece of the
PSTN act like a SIP proxy server and translate incoming call requests into
SIP INVITEs which then go to various user agent servers. The details of
the service logic inside this SIP proxy server should be placed there by
either CPL (whatever that will be) or proprietary means.

Sorry if I made too much noise.

Scott

---------