Subject: Re: What we have, what we don't have and need, what we don't need

From: [email-masked] (Igor Faynberg)
Date: Mon, 5 Apr 1999 14:02:29 -0400

While in an agreement with most of what Scott had written, I have a different
opinion on the following:

>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

Actually, the DPs and the criteria for their processing are standardized in
ITU-T. The standard is common for the US and Europe. 

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

I actually have not heard anyone who said on this list that that was not
the right model.

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

SIGTRAN is not dealing with ANY SS7 messages, so SIGTRAN will never do
anything with triggers.  (Nor is that what SIGTRAN needs to do.) What can we
do with the IN triggers?  Let us see, based on the example of Internet
Call Waiting:

1) A call arrives at the trigger "Called Party Busy."

2) A query is sent to the SCP.

3) SCP/Executive System/PIN Client realizes (by looking at the trigger) that 
either call redirection or call notification is needed, and sends an appropriateINVITE message. And the life starts.

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

Perhaps. But in order for the PSTN and Internet to cooperate, SIP would need
to know about the PSTN event, which--in the case of PIN--is a trigger!

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

No, no, no! There are only two state machines: Originating BCSM and Terminating
BCSM. Nothing else.  And even then, for the services that have been outlined
so far, we would need no more than two or three triggers. What we need
though is to develop a set of building blocks for all possible services.
To do so, we need no more than support the full list of triggers.

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

Two things: 1) If SIGTRAN transports actual IN messages around, we need no
PIN, no PINT, and no SIP. SCP will take care of everything. Nevertheless,
this is an expensive solution suitable to some but not all businesses. But
if we want to interwork SIP and IN, we will need to know WHEN to send SIP
messages and WHICH parameters to send them. In PINT, the Internet side
decides that; in PIN, the PSTN side. Trigger is a STARTING POINT. Thense
SIP can take over utilizing its own call model. (I am sort of repeating
myself, but in various tones and timbres. I am doing everything to be
convincing.)

Igor
SIP messages to send.

We will need
>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.
>

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

---

From: Chip Sharp <[email-masked]>
Date: Mon, 05 Apr 1999 14:48:50 -0400

>ITU-T. The standard is common for the US and Europe. 

While this is true, we do have to consider that because a DP is defined by
ITU it doesn't mean that it is available on a particular version of a
particular vendor's product.  Even if it is available, it doesn't mean a
telco has deployed it.  I don't think that IETF should track every such
permutation, it is a reality we have to deal with. :-\
But this isn't much different from any other telco protocol (ISDN, R2MFC,
SS7, etc.).

...snip...
>do with the IN triggers?  Let us see, based on the example of Internet

To clarify, sigtran will be transporting the SS7 messages to/from an IP
host where the messages will be processed.  Igor is correct in that sigtran
doesn't define any processing of SS7 application.  It is purely adaptation
and transport.

...snip...
>To do so, we need no more than support the full list of triggers.

So if we "do no more than support the full list of triggers" (you make it
sound so easy ;-), we will be able to interwork with all the various
vendor/national implementations out there?

>myself, but in various tones and timbres. I am doing everything to be

Well, sigtran is certainly working on a protocol that will be able to
transport IN messages over IP as long as they use "standard" TCAP or other
SS7 protocol.   sigtran will not be working on what the endpoints do with
these messages once they are received.  sigtran will also not be developing
any modifications to TCAP.

ETSI Tiphon has also identified a "reference point" between a Signaling
Gateway and a Gatekeeper that would conceivably transprot TCAP messages.

Of course, once you define a protocol to carry TCAP between an IP Host (IP
SCP?) and a Signaling Gateway, there is nothing keeping anyone from using
that protocol between two IP endpoints (IP SCP and SIP Server).  More fun. ;-)

>Igor
...snip...
--------------------------------------------------
Chip Sharp                 voice: +1 (919) 851-2085 
Cisco Systems              Consulting Eng. - Telco   
Reality - Love it or Leave it.			
--------------------------------------------------

---------

---

From: "Marty Tennant" <[email-masked]>
Date: Mon, 5 Apr 1999 15:10:06 -0400

A critical question that must be asked is - are there other
triggers active - particularly those that you might never have
asked for?  For example, BellSouth in Atlanta has implemented a
service called BusyConnect(sm).

They have activated an AIN 0.2 trigger on an officewide basis
called O_Called _Party_Busy so that the originating party never
get a busy signal, but a recorded announcement (advertisement)
advising you of the opportunity to press "1" to activate
BusyConnect, which turns around and dials *66 for you.

This is applied for orginating calls.  Are you referring to the
complementary T_Busy trigger below?  If so, what are the feature
interactions between the two triggers?  Which one has
precedence??

Perhaps Mr. A.R. Blackburn with BellSouth Technology would like
to address this.  Also, the Terminating Called Party Busy is an
AIN 0.2 trigger.  What makes you think this has been implemented
and will be available?  Very few 0.2 triggers have been, except
for the example above to my knowledge.

Marty Tennant
Low Tech Designs, Inc.

----- Original Message -----
From: Igor Faynberg <[email-masked]>

---------