2.7.10 PSTN and Internet Internetworking (pint)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98

Chair(s):

Steve Bellovin <smb@research.att.com>
Igor Faynberg <igor.faynberg@lucent.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

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

Jun 98

  

Submit Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations to IESG for publication as an Informational RFC.

Jul 98

  

Submit PINT Protocol Internet-Draft

Sep 98

  

Gain WG consensus on PINT Protocol draft

Jan 99

  

Submit PINT Protocol Draft to IESG to be considered as proposed standard

Jan 99

  

Produce first draft of PINT MIB Internet-Draft

Feb 99

  

Reach consensus on PINT MIB i-d

Apr 99

  

Submit PINT MIB ID to IESG for considratgion as a Proposed Standard.

Apr 99

  

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

Apr 99

  

Determine if WG is to continue or conclude.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2458

 

Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations

Current Meeting Report

Minutes of the PINT Meeting at the 43rd IETF Conference

(Reported by Steve Bellovin and Igor Faynberg, based on the notes taken by Lawrence Conroy, Hui-Lan Lu, and Lev Slutsman.)

The PINT WG met from 15:45 to 18:00 on December 8, 1998, with a 15 min. break from 16:45 to 17:00. The attendance list has registered 177 participants. The meeting was chaired by Steve Bellovin (AT&T Labs) and Igor Faynberg (Bell Labs, Lucent Technologies). The meeting notes were taken by Lawrence Conroy (Roke Manor Research/Siemens, Hui-Lan Lu (Bell Labs) and Lev Slutsman (AT&T), to whom many thanks.

Igor presented the agenda, which was accepted with no changes.

Scott Petrack (Vocaltec) made a short presentation on the two remaining PINT issues:
1) Security section needs a volunteer to provide any additional (to that of SIP security) material, if needed; and
2) registration of the numbers for services. These issues are to be addressed in on-line discussions in the courseof the next two months before the final version of the draft is issued.

Lawrence Conroy (Roke Manor Research, Siemens) addressed the mapping of PINT parameters to those of the InitiateCallAttempt operation of the Intelligent Network Application Part Protocol (INAP), and demonstrated that those are understandable to IN service logic. In the course of the presentation an issue of using the ACK message bodies for carrying additional information was raised. The discussion that followed resulted in the decision not to use the body of ACK in PINT. Another issue, that of the treatment of not understandable headers, had a simple resolution, too: ignore such headers.

Lev Slutsman (AT&T) presented a need for notification mechanism in order to avoid unnecessary PSTN circuit occupation when calls are queued. If the PINT protocol--in its present form--requests a connection between a calling party and, say, a call center in which all agents are busy, the calling party will be connected (via IN) to the announcement while waiting for an agent. (The calls that cannot be answered are normally put into a FIFO queue by IN.) There is nothing wrong with that because this is how the Freephone service works; however, the advantage of the Internet access can be used so as to inform the calling party about the queue progress and then establish the call only when there is an agent to answer it. Doing so will significantly decrease the use of circuitry (a resource that is becoming scarce) while improving the customer satisfaction. With the present IN facilities, the information about the queue size and anticipated waiting time is available at the SCF (and, subsequently, the PINT Executive System and PINT Server). Lev's proposal was to augment the PINT protocol with the feature by which, the PINT Client can request notification about the queue progress from the PINT Server. He suggested that the notification mechanism described in the recent mmusic WG draft "SIP for Presence" be used. There was a unanimous agreement that this feature was important. As far as the particular implementation is concerned, Jonathan Rosenberg, the co-author of both SIP and the draft in question, recommended that only the facilities of the latest SIP specification be used. He explained that the notification mechanism mentioned by Lev was put together for the Presence Information Protocol proposal, and was not intended to be part of the "core" SIP. To summarize, Lev's proposal can be implemented with the "core" SIP and the SUBSCRIBE/NOTIFY extensions that have been defined for PINT. Scott Petrack demonstrated that the present SUBSCRIBE/NOTIFY PINT mechanism, augmented by filtering, is sufficient to support the feature. There was no disagreement with that solution.

Scott expressed a concern over the way in which the PINT Client could address the Executive System; presently, it is impossible to to identify it. Lev agreed that the identification can be implicit (i.e. the PINT Client only "sees" the Gateway, and that sorts out any "back end" addressing needed).

Scott and Lawrence confirmed that the final copy of the PINT Protocol draft (including the example demonstrating an implementation of Lev's proposal) will be available in about two months.

That concluded the first part of the meeting agenda; the second part was dedicated to two informational presentations and the discussion of the future work.

Gilles Lecorgne, France Telecom-CNET/TINA-C, has presented the TINA-C status as well as its architecture, the PINT model in its context, and the areas in which TINA is planning to contribute to PINT. The chairs thanked Gilles and invited further communication from TINA-C on the result of the PINT-related prototyping work.

Alec Brusilovsky (Lucent Technologies) reported on an implementation of the Internet Call Waiting (ICW). The presentation generated much interest. It was noted that this implementation was particular to the needs of Local Exchange Carriers (LECs).

Finally, Steve Bellovin addressed the future work in PINT. He noted that the existence of the PINT MIB is not essential to the advancement of the PINT protocol draft to the 'proposed standard' status, which is the next milestone for PINT, but it will be necessary for the advancement to the 'draft standard' status. The MIB specification work should start, however, as soon as possible. (Igor mentioned that Dan Romascanu, the HUB MIB WG chair and a "MIB Doctor" has volunteered to work on the PINT MIB.) Meanwhile, the implementations are to be developed and reported to PINT. A request for show of hands of those who work on PINT implementations resulted in a count of five independent implementations in progress. While the implementations are progressing, the PINT WG may remain dormant (for about two meetings); meanwhile the proposals for the new work (if any) will be considered.

Slides

Agenda
PINT Parameter Issues
On Call Queuing in PINT
TINA and PSTN/Internet Interworking
Internet Call Waiting Service using SIP An Implementation Report