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:
· 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
· The PINT Profile of SIP and SDP: a Protocol for IP Access to Telephone Call Services
No Request For Comments
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
I. Faynberg (Bell Labs, Lucent Technologies) faynberg@bell-labs.com,
based on the notes taken by Hui-Lan Lu (Bell Labs),
Lawrence Conroy (Roke Manor Research/Siemens),
Jonathan Rosenberg (Bell Labs), and
Lev Slutsman (AT&T 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:
Additions to SIP & SDP
Parameters - pint_context, usage,
Forward & backward compatibility
Requirements for carriage via SIP infrastructure
16:05-16:35 Lawrence Conroy Issues relevant to Profile Context & Use:
Configurations
Registration behavior
Proxy behavior
Practicality of service naming
Privacy, SIP, and service requests
Open Issues:
* Nuisance Calls
* Malicious Call Interception
* Assuring Equal Access
* Anything else?
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:
New PINT time table
MIB work
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.
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