2.7.6 PSTN and Internet Internetworking (pint)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

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.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:

1) 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.

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

3) 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.

4) 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.

5) 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.

6) 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 Current Internet-Drafts
No Request For Comments

Current Meeting Report

Minutes of the PSTN/Internet Interworking Working Group Meeting

Reported by I. Faynberg (Bell Labs, Lucent Technologies) <faynberg@bell-labs.com>

The newly created PSTN/Internet Interworking (PINT) WG meeting took place from 15:30 to 17:30 on Wednesday, August 13. Igor Faynberg (Bell Labs/Lucent Technologies) chaired the meeting. The WG roster registers 131 attendees.

Hui-Lan Lu, Murali Krishnaswamy (both of same organization) took notes and helped to prepare this report, many thanks to them. Thanks also go to Allyn Romanow and Steve Bellovin who reviewed the report and provided constructive comments.

The agenda of the meeting was as follows:

I. Addressing PINT Charter (I. Faynberg)
II. A Small Tutorial on PSTN and IN (I. Faynberg)
III. Analysis of Services and Interfaces used when Interworking between the Internet and Intelligent Network (IN) (Lawrence Conroy, Roke Manor Research/Siemens)
IV. Information Exchange to be Supported by the Service Support Transfer Protocol (SSTP) (Hui-Lan Lu, Bell Labs/Lucent Technologies)
V. Introduction to the Session Initiation Protocol (SIP) (Mark Handley, USC/ISI)
VI. Discussion of the workplan (all).

I. Addressing PINT Charter (I. Faynberg)

In addressing the groups charter [item 1)], it was stressed that PINT is to study "the 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 or Fax machine and that the subjects of "Internet Telephony" (or "IP Telephony") are outside of the charter.

II. A Small Tutorial on PSTN and IN (I. Faynberg)

The IN tutorial [item 2)] emphasized the computing- and data communications-based aspects of the PSTN signaling architecture (which make the combination of the Internet and PSTN services possible) and introduced the key functional and physical entities standardized by the ITU-T to which relevant internet drafts have referred.

III. Analysis of Services and Interfaces used when Interworking between the Internet and Intelligent Network (IN) (Lawrence Conroy, Roke Manor Research/Siemens)

The PINT service analysis [item 3)] addressed both the charter of the group and the IN architecture and described in great detail the internetworking arrangement (with an emphasis on the Gateway functions) as well as the present "benchmark" hybrid services. Based on these services, the presentation provided a useful taxonomy of the services that require only service control request and those that require both service and data requests.

The presentation generated the following discussion:

Q: Does this arrangement handle the phone-to-PC calls?
A: No. Those are actually out of PINT's scope.

Q: Can an IP host be an end user?
A: Yes, for certain services (feasible, as far as the charter is concerned, but presently not discussed in PINT).

Q: Are the SS7-based protocols have to be used in this arrangement?
A: No. The SS7-based protocols are on the PSTN side only. In fact, the Internet side should only be aware of the PSTN capabilities, not the way they are implemented.

Q: Is the protocol to be standardized point-to-point or point-to-multipoint?
A: Point-to-point.

Q: The charter of PINT, as well as this presentation, excludes "call control" from work but supports "service control." What is the difference?
A: "Call control" is what the switch does (see the tutorial). There is no direct interface to the switch from the IP server (and it is inconceivable that it would ever be there!). Thus, PINT has nothing to do with call control. Service control, on the other hand, is a general computing function, and there are many ways in which Internet could enrich the IN-supported services.

Q: Why not re-use the existing (and developing) Internet protocols?
A: Of course, we should re-use them if they are applicable. This is why the SIP presentation has been included in the agenda.

IV. Information Exchange to be Supported by the Service Support Transfer Protocol (SSTP) (Hui-Lan Lu, Bell Labs/Lucent Technologies)

The SSTP Information exchange [item 4)] (based on the Lucent prototype experiences) was presented. The design choice was the reliable transport layer, the choice being dictated by the supported services . Those are the four initially defined for PINT (and introduced by Lawrence in the previous presentation). It was also pointed out that the reported experience was gained on the interconnection of the Web server to the Service Node.

Q: The architecture seems to differ from that presented by Lawrence. There was a Gateway there, but it is not mentioned here.
A: ITU-T has not formally specified a Gateway, although it is being considered. Presently the Gateway is a functional (rather than physical entity), and as such it could be implemented in either SN or SCP.

Q: But if a Gateway is a physical entity, then the protocol you are describing will be between the Gateway and the IP host?
A: That is correct. But it should be also remembered that the Gateway's job is to watch for things and filter the right things to the SCF. So, as far as the information exchange is concerned, it would be the same.

Q: Why do you need Transaction ID? TCP should take care of that.
A: This is because of the necessity to break up messages within one transaction. Both Internet Drafts submitted for today's discussions reported on the TCP limitations on the SN, which restricts the messages to be sent to smaller units than may be necessary for a message. Thus, TIDs are used for correlating messages pertinent to a specific transaction.

Q: The security of the proposed protocol is insufficient for internetworking.
A: That is true. Our experience has been with the case of a "trusted" IP host. Specifically, the web server and the SN were in the same administrative domain. PINT solicits help from the IETF security experts in providing the best solution.

Q: The problem is not (just) the traditional sort of problem, but one of preventing malicious calls. Or, to put it in security terminology, you have a lot of worry about authorization, and not just authentication.
A: Good point. Agreed.

Q: It looks like you are dealing with the thing at the edge of the network? Why do you need IN?
A: Although it is true that the SN is at the edge of the network (in that it uses the ISDN access protocol to the switches), it is a standardized IN entity. Furthermore, the SCP is not at the edge of the network.

Q: But what you want to do also applies to the Internet telephony. Why not develop the protocols that are applicable to that, too?
A: It is not in our charter. But if the insertion of certain "hooks for the future" is obvious to all, there should not be much problem in doing that.

Q: This also applies to PBX call centers. Things like SCAI.
A: True. SCAI is to PBXs is what IN is to the switches in the network. It is the difference between the fast on-premises connection to a switch versus the connection over the SS7 network that made the IN and SCAI become different standards (even though they do have much in common). As far as PINT is concerned, if the PBX world sees it applicable, the PINT results can be used for PBXs. On the other hand, what would be applicable to PBXs, a priori may not be applicable to IN. We should look at each specific proposal to decide what is appropriate. Again, the proposals are welcome!

Q: Why cannot you use the existing protocols? RPC, for example? How about the Internet fax?
A: We can and want to use the existing protocols. We have to learn them. SIP, for example, has been proposed to us, and Mark is going to present it now.

V. Introduction to the Session Initiation Protocol (SIP) (Mark Handley, USC/ISI)

Presentation of item 5 did not generate many questions, and the meeting proceeded toward the discussion of the working plan. One major issue that was debated at this point was whether PINT should include other services (i.e., PC-to-PSTN). The need to mention IN has been questioned, too, because its role was seen as "performing magic." The latter opinion did not have much support, however. Scott Bradner suggested that IN should be referenced in order to keep focus on specific (rather than abstract) capabilities.

The consensus was that SIP (perhaps combined with other protocols) can potentially be used by PINT, and that for this reason it must be studied. The PINT services should be defined in more detail (Scott Petrack offered to prepare the description). Security must be addressed even in the informational RFC (Steve Bellovin kindly offered his help). There may be additional services (conference calling was mentioned), but the benchmark must be completed before the protocol work can start.

The outline of the Informational RFC was found acceptable.

It was decided that the work should proceed by e-mail. No interim meetings were planned.

Slides

PINT - Agenda, Charter, and Workplan

Attendees List

go to list

Previous PageNext Page