@techreport{ietf-pint-conf-02, number = {draft-ietf-pint-conf-02}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-pint-conf/02/}, author = {Lev Slutsman}, title = {{A proposal for new PINT building blocks with applications to Conference Calling}}, pagetotal = 8, year = 2000, month = jan, day = 7, abstract = {The main purpose of this document is to propose new Conference Call Service for the PINT WG. This document contains a description of a Conference Call Service for PINT (CCSP), provides a non-exhaustive list of PINT requests (PINT Conference Building Blocks) to support them, and describes the needed extensions to the current PINT architecture. Current PINT services, such as Request to Call, use the Internet only to deliver service requests from an IP host to the PSTN to be executed there. However, limiting the PINT Conference service to just delivering the request to allocate the conference bridge to the PSTN, would hardly justify the practicality of the service. The PINT Conference Service described in this document allows for the following functionality: o manual or automated negotiation of conference parameters, such as date, agenda, etc., before the PSTN resources are committed; o requesting the PSTN to allocate the conference bridge; o requesting the PSTN to start the conference automatically by calling each participant at the specified time; A proposal for new PINT building blocks with applications to Conference Calling o monitoring real-time conference events by keeping track of the current speaker as well as of participants leaving or joining the conference bridge. Unlike the current PINT services, which require exactly one request per service, the proposed Conference Call Service with the above functionality, needs to be mapped into a number of PINT requests. In this paper we propose a non-exhaustive list of PINT requests to support the basic CCSP functionality. We also discuss the extensions to the current PINT architecture that are needed to support the CCSP. If the service proposal is approved by the PINT WG, the protocol issues such as profiling SIP, SDP, etc. will be addressed in the forthcoming documents. This document is intended for the PSTN-Internet Interworking (PINT) worki}, }