NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
Chair(s):
Steve Bellovin <smb@research.att.com>
Igor Faynberg <faynberg@bell-labs.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Transport Area Advisor:
Allyn Romanow <allyn@mci.net>
Mailing Lists:
General Discussion:pint@lists.research.bell-labs.com
To Subscribe: pint-request@lists.research.bell-labs.com
In Body: subscribe your-email-address
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 providing 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. |
Internet-Drafts:
· PSTN-Internet Internetworking - An Architecture Overview
· Pre-PINT Callback Service Implementation Experiences
· SIP for Click-To-Dial-Back and Third-Party Control
· IP Access to PSTN Services: Basic Service Requirements, Definitions, and Architecture
· Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations
No Request For Comments
Minutes of the PSTN and Internet Interworking (pint) Working Group
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 13 :00 to 15:00 on Wednesday, April 1. The meeting was chaired by Steve Bellovin (ATT Labs-Research) and Igor Faynberg (Bell Labs/Lucent Technologies). The WG roster registered 178 attendees.
Hui-Lan Lu, to whom many thanks, took notes and helped to prepare this report. Thanks also go to Vern Paxson and Lawrense Conroy for their comments on its first version.
The proposed agenda of the meeting was as follows:
1. 13:30-13:05 Chairs Agenda bashing
2. 13:05-13:25 H. Lu Status of the Informational RFC
3. 13:35-14:05 S. Petrack PINT Basics 01
4. 14:05-14:35 L. Conroy PINT Protocol Requirements
5. 14:35-14:50 A. DeSimone Call Broker Protocol for Requesting Telephony Services:
Authentication and Authorization
6. 14:50-15:00 H. Lu Defining the Structure of the Protocol RFC
7. 15:00 All Adjourn
Agenda bashing revealed that Tony DeSimone could not come to the meeting; as no one else could present this material, item (5) was taken off the agenda, and the resulting extra time was divided among the rest of the speakers. No other changes to the agenda were proposed.
During the discussion of item (2), a question was asked regarding detailed implementation of the click-to-fax service. Following a satisfactory response by the presenter, the request was made to include this information into the text. It was decided that the latter request be discussed on-line; depending on the opinions of the group as well as that of the original author of the text, the requested information could be included in the final version of the draft. An important point of the presentation was clarification of the mapping of the PINT Gateway function into the SCP and SN; that mapping has implicitly been part of all the implementations described in the draft.
The Editor also announced that the next (final before the WG last call) version of the document will come in a month and requested that all comments should be sent before then.
Item (3) (actually entitled "Realizing PINT services: A PINT profile for SIP/SDP") addressed the development of PINT protocol; its highlights include the proposal for the new GSTN connection type, considerations of the semantics of data and text, examples of media descriptions, and third party authorization. (The latter specifically included a proposal to extend SIP by the addition of two headers: 'AuthorizationTo' and 'AuthorizationData'. The presentation raised a set of important open issues regarding the protocol work. The issues and (their respective resolutions) are as follows:
Issue 1: Should the PINT protocol support Multiparty calls?
Resolution: It may (as long as it comes "for free", without producing any additional requirements for the protocol), but it does not have to, because the initial PINT services do not require that feature.
Issue 2: Should the PINT protocol support call control?
Resolution: [By chairmen intervention.] No, this is outside of the present PINT charter. Our goal is to finish the work specified by the charter. Until that is done, we may not discuss any other work, no matter how reasonable and feasible it is.
Issue 3: Representation of GSTN numbers (e.g., use of alphabet letters in place of digits).
Resolution: Start the on-line discussion of this subject (which started a lively interaction).
Issue 4: Should the PINT request carry in-line data?
Resolution: Yes, inasmuch as it can be allowed by the UDP constraint on the data size.
Issue 5: Should the third party authorization be allowed?
Resolution: UNKNOWN--PLEASE HELP
There was also a discussion of queuing and status information exchanged with the PSTN. It was noted that this will be best taken care of by the PSTN itself. Nevertheless, the issue is to remain open pending new arguments.
Item (4) provided an overview of the requirements for the protocol. This included the following: a) the set of services (with the clarification that took in account the latest submission to PINT before the meeting [the credit for which goes to D. Shroeder, Bellcore], which states that only Internet - initiated Voice Access to Content is to be considered); b) the information to be carried by the protocol (service request and parameters, related data objects, requesting user ID, and authority token); c) the protocol syntax (SIP/SDP with extensions); d) profiling, examples and service descriptions; operational requirements (secured link, request transfer, data transport, authentication, and authorization); e) a scenario in which the PINT Gateway is connected to the SCF and SRF; and d) and the set of open issues (detailed mechanism for authentication; potential use of Transport Layer Security [TLS] for authorization; and the form of "extandible" extensions).
The presentation raised a few questions but no disagreements. One important question asked concerned the division of work between the ITU-T and IETF. This was explained using the architectural model. Specifically, the interface between the PINT Gateway and the IP server is to be standardized by the IETF; the interfaces between the PINT Gateway and the IN Functional Entities is to be standardized by the ITU-T SG 11. The chairs also confirmed that ITU-T SG 11 WP 4/IN and PINT are working closely on this particular item.
Item (6) proposed the outline of the PINT Protocol Document, which was accepted with minor corrections. The final version of the outline is as follows:
1. Introduction
2. Terminology
3. PINT Services
4. Functional Interconnection Architecture
5. PINT Protocol Components
- SIP
- SDP
- (TBD)
6. Protocol Procedures (i.e., sequencing of messages; preferably using Finite State Machines)
7. Protocol Syntax
8. Security Considerations
Lawrence Conroy and Scott Petrack agreed to serve as Document Editors for this document.
PINT Protocol Requirements
PINT - Agenda
Realizing PINT Services: a PINT Profile for SIP/SDP
Current Status of the Informational Draft