Subject: What we have, what we don't have and need, what we don't need (fwd)

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

A resend, hopefully bell-labs will find the smtp relay I found acceptable
:-(.

---------- Forwarded message ----------
Date: Sun, 4 Apr 1999 21:44:22 -0400 (EDT)
From: Scott Petrack <[email-masked]>
To: pint list <[email-masked]>
Cc: pin list <[email-masked]>
Subject: What we have, what we don't have and need, what we don't need

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

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

---

From: Alec Brusilovsky <[email-masked]>
Date: Mon, 05 Apr 1999 13:45:27 -0400

>         Subscription to a particular service

Let me add some other candidates for PIN services from our BOF I-D
http://search.ietf.org/internet-drafts/draft-brusilovsky-pin-00.txt :

   o Voice-mail Arrival.
   o  Incoming Call Notification (Attempt to Terminate Call).
   o Attempt to dial number (specific event can be Attempt to Dial  ISP
Number.
   o  Dropping Dialed Connection (i.e. dropping ISP call).
   o  ISP Connection Made.
   o  Attempt to Forward Call (forwarded end point could easily be VoIP
terminal).
   o  Attempt to Subscribe/Unsubscribe for a PSTN Service (i.e.  Set  Up Call
Forwarding).
   o  Attempt to Enter Conference. (Notification only)
   o  Attempt to Exit Conference. (Notification only)
   o  Identification  of  the  Speaker  (talking  party)  to  the other
participants of the Voice (or  multimedia)  Conference  (Notification
   only).

> simply-worded service definitions (with enough ambiguous generality so that
> everyone's variation can be covered

One of the results of PIN BOF in Minneapolis was a decision to write an
Informational RFC to address and describe proposed PIN services. I know for
sure that Lawrence Conroy has kindly volunteered (among other people) to
participate in that effort. Hopefully, we will be able to depict these
services with enough generality.

>                 events, and there is an assumption that the two sides are

Scott, great list of building blocks. Helped me a lot. Thank you for composing
it.

Let me just add that Subscribe/Notify methods, so well described by Scott, are
different from a subscription part of PIN services. As we discussed before,
some PIN services require subscription (or service set up) per one core
service firing, some other require one subscription per many core service
firings. In the latter case we can, actually, separate Subscription Service
from Core PIN service.

>         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

Scott, this is an overly simplified, or an overly complicated picture. The
truth is that even though IN has several standards (and a single standard
defined by ITU-T), the "genetic mutations" between them are not as far apart.
We can, definitely, find and focus on a generic part. Lev Slutsman is an
expert in IN standards and I would like him to help all of us with the
clarification.

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

I, personally, think that PINT model is quite applicable for PIN services. As
soon as we finish with defining PIN services and proceed with PIN requirements
we will, definitely, come back to scrutinize the PINT model. Thank you for
bringing up the issue.

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

The primary purpose of SIGTRAN is "to address the transport of packet-based
PSTN signaling over IP Networks, taking into account functional and
performance requirements of the PSTN signaling. For interworking with PSTN, IP
networks will need to transport signaling such as Q.931 or SS7 ISUP messages
between IP nodes such as a Signaling Gateway and Media Gateway Controller or
Media Gateway.

Examples of such transport include:

- transport of signaling between a Signaling Gateway and Media Gateway or
Media Gateway Controller - transport of signaling
("backhaul") from a Media Gateway to a Media Gateway Controller
- transport of TCAP between a Signaling Gateway and other IP nodes " - a
quotation from SIGTRAN charter.

As I understand, SIGTRAN is not supposed (at least currently) to open
transported messages.

>
> 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.
>         d) This means that we can't do PSTN third party call control. (This
> is not a terrible emergency -- the PSTN can't really
> "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).
>
> variants of "call transfer" that have been standardized. This is truly not a
> productive use of time.
>

Those hundreds of variants of "call transfer" (I have doubts about hundreds,
but am taking this as a metaphor) were standardizes in different standard
bodies, with different rules and procedures than IETF. IETF has a different
standard practice and we are aiming for one standard to be defined.

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