2.7.7 PSTN and Internet Internetworking (pint)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 04-Nov-97


Steve Bellovin <smb@research.att.com>
Igor Faynberg <faynberg@bell-labs.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn.romanow@eng.sun.com>

Transport Area Advisor:

Allyn Romanow <allyn.romanow@eng.sun.com>

Mailing Lists:

General Discussion:pint@lists.research.bell-labs.com
To Subscribe: pint-request@lists.research.bell-labs.com
In Body: subscribe your-email-addres
Archive: http://www.bell-labs.com/mailing-lists/pint/

Description of Working Group:

The PSTN/Internet Interfaces (PINT) WG addresses connection arrangements through which Internet applications can request and enrich PSTN (Public Switched Telephone Network) telephony services. An example of such services is a Web-based Yellow Pages service with the ability to initiate PSTN calls between customers and suppliers.

This working group has six main objectives:

* Study 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, FAX machine). The protocols are not to support any form of third-party call control or, for that matter, any type of call control; their role is rather to securely carry call requests to the PSTN. Specific services to be considered initially are Click-to-Dial, Click-to-Fax, Click-to-Fax-Back, and Web access to voice content delivered over the PSTN.

* Produce an informational RFC that describes current practices for supporting the services in question.

* Based on the existing practice and agreed on improvements, develop a standards track RFC that specifies a Service Support Transfer Protocol (SSTP) between Internet applications or servers and PSTN Intelligent Network Service Nodes (or any other node that implement the Service Control Function). SSTP is an application-specific transport protocol operating over TCP.

* Consider security issues relating to prividing functions of this type. In particular understand any threats posed by this technology and resolve them, and any other security issues in the proposed standard.

* Based on the existing practice and agreed on improvements, develop a standards track RFC for a relevant MIB (SSTP MIB) to support the service management protocol between Internet applications and the PSTN Service Management System. The SSTP MIB is to conform to SNMP standards.

* Consider extensions of the above architecture and protocols to support a wider range of PSTN Intelligent Network (IN) based services.

Goals and Milestones:

Aug 97


First WG meeting at Munich to discuss 2 submitted drafts and begin work on the informational rfc and on SSTP.

Oct 97


Issue first draft of Internet-Draft intended for Informational.

Oct 97


Issue first draft of SSTP Internet-Draft

Dec 97


Meet at Washington IETF to gain WG consensus on informational draft

Jan 98


Submit Internet-Draft to IESG for publication as an Informational RFC

Apr 98


Gain WG consensus on SSTP draft

May 98


Produce first draft of MIB Internet-Draft

Jun 98


Submit SSTP to IESG to be considered as proposed standard

Aug 98


Reach consensus on MIB i-d

Sep 98


Submit MIB i-d for promotion to proposed RFC status

Sep 98


Submit any proposals for future work, to be done by a new WG if accepted

Oct 98


Determine if WG is to continue or conclude.


No Request For Comments

Current Meeting Report

Minutes of the PSTN/Internet Interworking (pint) WG

Reported by: S. Bellovin (AT&T Labs-Research) smb@research.att.com and
I. Faynberg (Bell Labs, Lucent Technologies) faynberg@bell-labs.com,
Based on the notes taken by Hui-Lan Lu (Bell Labs).

The PSTN/Internet Interworking (PINT) WG meeting took place from 19 :30 to 22:00 on Wednesday, December 10. The meeting was chaired by Steve Bellovin (ATT Labs-Research) and Igor Faynberg (Bell Labs/Lucent Technologies). The WG roster registers 155 attendees.

Hui-Lan Lu, to whom many thanks, took notes and helped to prepare this report.

The proposed agenda of the meeting was as follows:

2) 19.35-19:55, L. Conroy, Pre-PINT Service Implementation Experiences
3) 19:55-20:10, M. Krishnaswamy, Pre-PINT Implementation Report
4) 20:10-20:35, S. Petrack, IP Access to PSTN Services: Basic Service Requirements Definitions and Architecture
5) 20:35-20:55, H. Schulzrinne , SIP for Click-to-Dial-Back and Third-Party Control
6) 20:55-21:10, S. Bellovin, On Security Requirements for PINT
7) 21:10-21:30, P. Davidson, A Proposal for a Simple Computer Telephony Protocol
8) 21:30-21:45, F. Burg, An Architecture and Protocols for Initiation and Controlof Telephone Calls From Terminals Connected to a CallBroker over a TCP/IP Connection.
9) 21:45-21:55, Hui-Lan Lu, Putting together an Informational RFC
10) 21:55-22:00, Chairs , Work items for the next quarter
11) 22:00, All, Adjourn

During the discussion of item (1) it was proposed and agreed to present item (6) ahead of item (4). In addition, item (8) was moved ahead of item (6), and Tony DeSimone (AT&T) was named its presenter. It was also announced that after the meeting Fred Burg would give a demo supporting the presentation.

Item (2) presented the Siemens pre-PINT implementation experiences as proposed for the Informational RFC. Responding to questions, Lawrence Conroy pointed out that the ITU-T CS-1 INAP was used in the prototype and that the protocol with the gateway was service-independent. There was no disagreement with the presented material.

Item (3) presented the Lucent pre-PINT implementation experiences, as proposed for the Informational RFC. Murali Krishnaswamy announced that part of his draft summarized the material that had already been presented to PINT, for which reason his presentation was focused on the new aspect: the structure of Management Information Base (MIB), which he had implemented. Responding to questions, Murali explained that the SMS role was to provision the service logic to the service node, and that the Service Data Function (SDF) was implemented as part of the service node. There was no disagreement with the presented material.

Item (4) presented the proposed terminology and service requirements (and scenarios) destined for the future standards-track RFC. Scott Petrack clarified, in response to questions, that a) the word "terminal" refers to telephone terminals (not IP hosts) and b) PINT Clients and PINT Servers are IP hosts. There were no disagreements, but two concerns were expressed:

1) The issue of potential overlapping of authorization domains
2) Some services (like conference calling) that rely on the call-control-related features that are outside the present PINT charter.

The first issue has been taken off-line; it will be resolved in consultation with the Area Directors. As far as the second issue is concerned, both chairmen re-affirmed that only the charter-related material is relevant to the meeting; the rest of it, although of high quality and interest to others, will be retained in waiting until the present charter has been completed.

Item 8 (presented by Tony DeSimone of AT&T) shared a company experience with the implementation of "click-to-dial-back" service. This presentation was unique in that it demonstrated relevant API. This has raised a question of whether AT&T had patents related to the subject. All members of the working group were referred to RFC 2026. Briefly, working groups are free to adopt patent-encumbered technology; however, the patent owners must agree to license the patents on reasonable and non-discriminatory terms. Furthermore, anyone who submits a mechanism that may be protected is obligated to disclose any encumberances he or she is aware of. Finally, anyone and everyone is invited to make the IESG aware of any patents pertaining to any standards-track RFC. In response to other questions, Tony pointed out the interface between the call broker and the switch is a) IP-based, b) reflects the client-server model, and c) in the current implementation, the call broker resides in the telecom server domain (not in the Internet domain).

Item 6 presented security requirements for PINT. There were no objections and no questions.

Item 5 demonstrated the use of SIP (which is, the protocol of choice for PINT) for supporting click-to-dial-back and other PINT services. In response to a suggestion to have more flexible SDP for passing call-related information, Henning invited contributions on this topic.

Item 7 presented SCTP to start a discussion on how this protocol fits within PINT. During the discussion it was noted that the SCTP is a feature-rich CTI protocol that can serve well as the transport mechanism supporting various APIs (e.g., S.100, TSAPI, and JTAPI). A concern was expressed whether the SCTP would be appropriate for the Internet. To address this concern, Paul mentioned that the SCTP, just in order to be useful for the Internet, has been based on the HTTP. The other concern, which still remains open, is how exactly the SCTP can be used to support PINT services efficiently.

Item 9 presented the outline of the Informational RFC (no disagreement) and expressed the editor's intention to complete the draft by the end of January.

The chairmen thanked the presenters and audience for active, cheerful and cooperative participation, thanks to which an unusually large agenda was covered. The PINT participants were asked to request their time slots for future meetings before the dead-line so that sufficient meeting time be scheduled.


None Received

Attendees List

go to list

Previous PageNext Page