2.7.10 PSTN and Internet Internetworking (pint)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 31-Jul-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

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:

No Request For Comments

Current Meeting Report

Minutes of the PSTN/Internet Interworking (pint) WG
Meeting on August 27, 1998

Reported by: S. Bellovin (AT&T Labs-Research) smb@research.att.com and

based on the notes taken by Hui-Lan Lu (Bell Labs),

The PSTN/Internet Interworking (PINT) WG meeting took place from 15:30 to 17:30 on
Thursday, August 27. The meeting was chaired by Steve Bellovin (ATT Labs-Research)
and Igor Faynberg (Bell Labs/Lucent Technologies).

Hui-Lan Lu, Lawrence Conroy, Jonathan Rosenberg, and Lev Slutsman, to whom many
thanks, took notes and helped to prepare this report.

The proposed agenda of the meeting was as follows:

15:30-15:35 Chairs Introduction and Agenda Bashing

15:35-16:05 Scott Petrack Issues relevant to the PINT Protocol Profile:

16:05-16:35 Lawrence Conroy Issues relevant to Profile Context & Use:

Privacy, SIP, and service requests

* Nuisance Calls

16:35-17:05 Hui-Lan Lu, The status of the counterpart work in the ITU-T
Greg Ratta

17:05-17:30 Chairs Where we go from here:

In the introduction, the chairs summarized the status of the PINT work:

1) completion and approval by the IESG of the PINT informational RFC, which has
been presently undergoing the editorial changes requested by the RFC editor;

2) completion of the first draft of the PINT Protocol; establishment of "liaison" (or, more
precisely, mutual representation with the ITU-T Study Group 11 Working Party 4 (re:
Intelligent Network). It was noted that some confusion was caused by the SS7 BOF
preparatory discussion, which was cross-posted to several lists, including the PINT list.
Neither the IP telephony requirements nor suggestions concerning the future PINT work
were among the issues to be discussed within the scope of the present PINT charter.

Concerning the agenda, the chairs informed the meeting that no TINA representative was
able to come to the IETF; the extra 15 min. were appended to the last item of the agenda.
It was also noted that the the official representative to PINT from WP 4/11, Prof. Mi of
China PTT, could not come to the 42nd IETF meeting. Hui-Lan Lu (who represents PINT
in SG 11) was asked to respond to questions regarding the SG 11 side of the story. (The
official document was submitted to PINT by Greg Ratta on behalf of SG 11.)

The agenda bashing resulted in two proposals:

1) Henning Schulzrinne (Columbia University) requested a 15 min. slot to address the
SDP issues; the request was granted.

2) Fred Burg (AT&T) requested that the use of H.323 for PINT be addressed; however, no
one wished to make a presentation on the subject. There was a comment suggesting a
need to consider "interworking between SIP and H.323" in the future work. On request
of AD, the discussion was postponed until the last item on the agenda (future work), but,
again, no one brought the subject up then.

The discussion of Scott Petrack's presentation raised the following questions:

a) Use of the country-specific freephone numbers (can, for example, '1-800-flowers' be
specified as a parameter?). This issue needs to be resolved in the mailing list discussions.

b) What if a wrong SDP parameter (i.e., 'wave') is specified in the body of the message?
How to prevent that? The proposal was made not to deal with that issue in a standard,
but leave that to implementations. A reference was made to the version 9 of the SIP I-D
for the use of warning headers inside responses. It was decided to follow up on the
mailing list.

c) Can the status information (specified in the new draft of SIP) be provided both
synchronously (to the request) and asynchronously? The answer: Yes. In fact, the
duration for which the event notification is provided can be specified.

d) Concerning the reference to the Draft ITU-T Recommendation Q.1241, is it used for
normative or informative reference (the normative reference would be inappropriate)?
The answer: the reference is only informative.

e) How to deal with the "Invite" redirect? It was noted that this problem is synergetic with
that of the IPTEL Gateway location and therefore should be left out of the PINT Profile.
(Another synergy with IPTEL was in the use of the Request message.)

An issue was also raised whether specification of the fax format is relevant to PINT. The
response was: Yes, we need to specify the format because we are transferring the source
data with the request. It was emphasized that this has nothing to do with Internet faxing--
the fax delivery is carried purely by the PSTN. Scott will provide the clarification text in
the next version of the draft.

Another question was on relation of the PINT Server and Executive System to the "Service
Node" of the PINT Charter. Scott Bradner noted that at the time the charter was written that
term was used, but now it is clear that was not the best choice. I. Faynberg seconded this
observation, mentioning that the ITU-T SG 11 came to the same conclusion, and noted that
the relation of the Executive System to Service Node and other IN physical entities will be
explained in Hui-Lan's presentation.

The discussion of Lawrence Conroy's presentation raised the following questions:

a) Are conferencing and multicasting supported in PINT? The answer: Not in the present
phase. Only requests for two party calls are supported by the PINT Protocol.

b) Can same services be delivered by IP telephony? The answer: It is likely, but this is
not the PINT WG concern.

The discussion of Henning Schulzrinne presentation (which proposed simplified session
description) raised an issue of support (with the proposed description mechanisms) of
invitations scheduled for some time ahead. This issue was deferred for the follow-up on-
line discussion.

The discussion of Hui-Lan's presentation raised no issues. The architecture she presented
was used to point out the entities (the SCF, SDF, SRF, and the SSF/CCF), whose
combination maps into the Service Node mentioned in the PINT charter; it was noted that
other combinations (e.g., SCF and SDF, for the Service Control Point) were also possible.

During the discussion of the reviewed milestones, Steve Bellovin pointed out that the
completion of the work on the PINT MIB is necessary for advancing the status of the future
PINT Protocol RFC to Draft Standard. A suggestion was made that this work be synergetic
with that of the SIP MIB (the PINT extensions would make the PINT MIB). The suggestion
was supported; the final decision was deferred to the "MIB doctors" who will pick up the work.

At the end of the meeting, it was suggested that the future PINT meetings will dedicate more
time to discussions (and less time to "tutorials"). The suggestion was supported by the chairs.
It was also noted that the decisions are actually made in on-line discussions, not at the meetings.

Slides

PINT enhancements to SDP/SIP
A Functional Architecture for the IN Support of the Internet -- the ITU- T SG11 View
PINT Profile Usage
SDP- related issues

Attendees List

go to list