Minutes of the PSTN/Internet Interworking (pint) WG 
                Meeting on April 13, 1997

		Reported by I. Faynberg
                 (Bell Labs, Lucent Technologies)

		faynberg@bell-labs.com 


	The newly-created PSTN/Internet Interworking (PINT) WG meeting took 
place from 15:30 to 17:30 on Wednesday, August 13. The meeting was chaired by 
Igor Faynberg (Bell Labs/Lucent Technologies).  The WG roster registers 131 
attendees. 

	Hui-Lan Lu, Murali Krishnaswamy (both of same organization) took notes
and helped to prepare this report; many thanks to them.  Thanks also go to
Allyn Romanow and Steve Bellovin who reviewed the report and provided
constructive comments.

	The agenda of the meeting was as follows:

  1) Addressing PINT Charter (I. Faynberg);

  2) A small tutorial on PSTN and IN (I. Faynberg);

  3) Analysis of Services and Interfaces used when Interworking between the 
     Internet and Intelligent Network (IN) (Lawrence Conroy, Roke Manor 
     Research/Siemens);

  4) Information Exchange to be supported by the Service Support Transfer
     Protocol (SSTP) (Hui-Lan Lu, Bell Labs/Lucent Technologies)

  5) Introduction to the Session Initiation Protocol (SIP) (Mark Handley, 
     USC/ISI)
        
  6) Discussion of the workplan (all).
                                         
	In addressing the groups charter [item 1)] it was stressed that PINT
is to study "the architecture and protocols needed to support services
in which a user of the Internet requests initiation of a telephone (i.e.,
PSTN-carried) call to a PSTN terminal (i.e., telephone or Fax machine" and
that the subjects of "Internet Telephony" (or "IP Telephony") are outside of
the charter.

	The IN tutorial [item 2)] emphasized the computing- and
data communications-based aspects of the PSTN signaling architecture 
(which make the combination of the Internet and PSTN services possible) and 
introduced the key functional and physical entities standardized by the ITU-T
to which relevant internet drafts have referred.

	The PINT service analysis [item 3)] addressed both the charter
of the group and the IN architecture and described in great detail the
internetworking arrangement (with an emphasis on the Gateway functions) as
well as the present "benchmark" hybrid services. Based on these
services, the presentation provided a useful taxonomy of the services that
require only service control request and those that require both service and
data requests. 

The presentation generated the following discussion:

	Q: Does this arrangement handle the phone-to-PC calls?
        A: No. Those are actually out of PINT's scope.

	Q: Can an IP host be an end user?
        A: Yes, for certain services (feasible, as far as the charter is 
           concerned, but presently not discussed in PINT).

	Q: Are the SS7-based protocols have to be used in this arrangement?
        A: No. The SS7-based protocols are on the PSTN side only. In fact,
           the Internet side should only be aware only of the PSTN capabilities,           not the way they are implemented.

	Q: Is the protocol to be standardized point-to-point or point-to-
           multipoint?
	A: Point-to-point.

	Q: The charter of PINT, as well as this presentation, excludes "call
           control" from work but supports "service control." What is the
           the difference?
	A: "Call control" is what the switch does (see the tutorial). There
           is no direct interface to the switch from the IP server (and it
           is inconceivable that it would ever be there!). Thus, PINT has
           nothing to do with call control. Service control, on the other
           hand, is a general computing function, and there are many ways
           in which Internet could enrich the IN-supported services.

	Q: Why not re-use the existing (and developing) Internet protocols?
        A: Of course, we should re-use them if they are applicable. This is
           why the SIP presentation has been included in the agenda.

	The SSTP Information exchange [item 4)] (based on the Lucent prototype
experiences) was presented. The
design choice was the reliable transport layer, the choice being dictated
by the supported services . Those are the four initially defined for PINT (and 
introduced by Lawrence in the previous presentation). It was also pointed out
that the reported experience was gained on the interconnection of the Web
server to the Service Node. 

	Q: The architecture seems to differ from that presented by Lawrence.
           There was a Gateway there, but it is not mentioned here.
        A: ITU-T has not formally specified a Gateway, although it is being
           considered. Presently the Gateway is a functional (rather than
           physical entity), and as such it could be implemented in either
           SN or SCP.

	Q: But if a Gateway is a physical entity, then the protocol you are
           describing will be between the Gateway and the IP host?
        A: That is correct.  But it should be also remembered that the
           Gateway's job is to watch for things and filter the right things
           to the SCF. So, as far as the information exchange is concerned,
           it would be the same.

	Q: Why do you need Transaction Id?  TCP should take care of that.
	A: This is because of the necessity to break up messages within one
           transaction. Both Internet Drafts submitted for today's discussions
           reported on the TCP limitations on the SN, which restricts the
           messages to be sent to smaller units than may be necessary for
           a message. Thus, TIDs are used for correlating messages pertinent
           to a specific transaction.

	Q: The security of the proposed protocol is insufficient for
           internetworking.
	A: That is true. Our experience has been with the case of a "trusted"
           IP host. Specifically, the web server and the SN were in
           the same administrative domain. PINT solicits help from the
           IETF security experts in providing the best solution.

	Q: The problem is not (just) the traditional sort of problem,
           but one of preventing malicious calls.  Or, to put it in security
	   terminology, you have a lot of worry about authorization, and not 
           just authentication.
	A: Good point. Agreed.

	Q: It looks like you are dealing with the thing at the edge of
           the network? Why do you need IN?
	A: Although it is true that the SN is at the edge of the network (in
           that it uses the ISDN access protocol to the switches), it is a 
           standardized IN entity. Furthermore, the SCP is not at the edge of
           the network.

	Q: But what you want to do also applies to the Internet telephony.
           Why not develop the protocols that are applicable to that, too?
	A: It is not in our charter. But if the insertion of certain "hooks
           for the future" is obvious to all, there should not be much 
           problem in doing that.

	Q: This also applies to PBX call centers. Things like SCAI.
	A: True. SCAI is to PBXs is what IN is to the switches in the network.
           It is the difference between the fast on-premises connection to a 
           switch versus the the connection over the SS7 network that made
           the IN and SCAI become different standards (even though they do
           have much in common). As far as PINT is concerned, if the PBX world
           sees it applicable, the PINT results can be used for PBXs. On the
	   other hand, what would be applicable to PBXs, a priori may not be
           applicable to IN. We should look at each specific proposal to
           decide what is appropriate. Again, the proposals are welcome!
	Q: Why cannot you use the existing protocols? RPC, for example? How
           about the Internet fax? 
	A: We can and want to use the existing protocols. We have to learn
           them. SIP, for example, has been proposed to us, and Mark is going
           to present it now. 

	Presentation of item 5 did not generate many questions, and the meeting
proceeded toward the discussion of the working plan. One major issue that was
debated at this point was whether PINT should include other services (i.e.,
PC-to-PSTN). The need to mention IN has been questioned, too, because its role 
was seen as "performing magic." The latter opinion did not have much support,
however. Scott Bradner suggested that IN should be referenced in order to keep
focus on specific (rather than abstract) capabilities.

	The consensus was that SIP (perhaps combined with other protocols)
can potentially be used by PINT, and that for this reason it must be studied.
The PINT services should be defined in more detail (Scott Petrack offered
to prepare the description). Security must be addressed even in the
informational RFC (Steve Bellovin kindly offered his help). There may be 
additional services (conference calling was mentioned), but the benchmark must 
be completed before the protocol work can start. 

	The outline of the Informational RFC was found acceptable.

	It was decided that the work should proceed by e-mail. No interim
meetings were planned.