NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 01-Apr-98
Jonathan Rosenberg <email@example.com>
Transport Area Director(s):
Scott Bradner <firstname.lastname@example.org>
Allyn Romanow <email@example.com>
Transport Area Advisor:
Allyn Romanow <firstname.lastname@example.org>
To Subscribe: email@example.com
Description of Working Group:
Before Internet telephony can become a widely deployed service, a number of protocols must be deployed. These include signaling and capabilities exchange, but also include a number of "peripheral" protocols for providing related services.
The primary purpose of this working group is to develop two such supportive protocols and a frameword document. They are:
1. Call Processing Syntax. When a call is setup between two endpoints, the signaling will generally pass through several servers (such as an H.323 gatekeeper) which are responsible for forwarding, redirecting, or proxying the signaling messages. For example, a user may make a call to firstname.lastname@example.org. The signaling message to initiate the call will arrive at some server at bigcompany. This server can inform the caller that the callee is busy, forward the call initiation request to another server closer to the user, or drop the call completely (among other possibilities). It is very desirable to allow the callee to provide input to this process, guiding the server in its decision on how to act. This can enable a wide variety of advanced personal mobility and call agent services.
Such preferences can be expressed in a call processing syntax, which can be authored by the user (or generated automatically by some tool), and then uploaded to the server. The group will develop this syntax, and specify means of securely transporting and extending it. The result will be a single standards track RFC.
2. In addition, the group will write a service model document, which describes the services that are enabled by the call processing syntax, and discusses how the syntax can be used. This document will result in a single RFC.
3. Gateway Attribute Distribution Protocol. When making a call between an IP host and a PSTN user, a telephony gateway must be used. The selection of such gateways can be based on many criteria, including client expressed preferences, service provider preferences, and availability of gateways, in addition to destination telephone number. Since gateways outside of the hosts' administrative domain might be used, a protocol is required to allow gateways in remote domains to distribute their attributes (such as PSTN connectivity, supported codecs, etc.) to entities in other domains which must make a selection of a gateway. The protocol must allow for scalable, bandwidth efficient, and very secure transmission of these attributes. The group will investigate and design a protocol for this purpose, generate an Internet Draft, and advance it to RFC as appropriate.
Goals and Milestones:
Issue first Internet-Draft on service framework
Submit framework ID to IESG for publication as an RFC.
Issue first Internet-Draft on Call Processing Syntax
Submit Call processing syntax to IESG for consideration as a Proposed Standard.
Achieve consensus on basics of gateway attribute distribution protocol
Submit Gateway Attribute Distribution protocol to IESG for consideration as a RFC (info, exp, stds track TBD)
No Current Internet-Drafts
No Request For Comments
Minutes for the IPTEL (IP Telephony) Workgroup meeting
Reported By: Wilhelm Wimmreuter
Prepared By: Jonathan Rosenberg, Wilhelm Wimmreuter
The IPTEL working group session was held on Wednesday evening. There were approximately 200 people attending. The working group was chaired by Jonathan Rosenberg, from Bell Laboratories.
1. Agenda Bashing - Jonathan Rosenberg [5 min.]
2. Charter Review and discussion - Jonathan Rosenberg [25 min.]
3. ETSI TIPHON liaison - Louise Spergel and Gur Kimchi, [15 min.]
4. Presentation on Sieve, followed by discussion - Tim Showalter, [25 min.]
5. ECTF CTI Call Models, followed by discussion - Peter Kozdon, [25 min.]
6. Call Processing Syntax development efforts, followed by discussion - Jonathan Lennox, [25 min.]
7. Moving forward - Jonathan Rosenberg [5 min.]
2. Charter Review and Discussion - Jonathan Rosenberg
A brief introduction of the History of IPTEL was given. The group started out as the siptel BOF, originally proposed to develop SIP for IP telephony. The focus of the group changed to explore those telephony services which more orthogonal to signaling protocols, for which there was existing efforts elsewhere. The charter proposed at the BOF covered three items:
· User location
· Call Processing Syntax
· Gateway location protocol
The first item was removed from the charter by the IESG, as Scott Bradner indicated, because of its broader scope and applicability to other efforts.
Jonathan then presented a technical overview of the call processing syntax effort. The syntax is a textual description of the desired behavior of a network server (which could be a SIP server, gatekeeper, or any other device capable of performing call processing) from a users perspective. End users are not the only ones who might create such scripts; system administrators shall be able to write this scripts. Third party call logic providers might provide such syntax scripts for additional services. The syntax might also be generated by programs, guided by some GUI for example.
A number of questions and issues came up regarding the precise nature of the service provided by the syntax. For example: can the script execute mid call? Would it be able to redirect a call in the middle, based on user input (from DTMF, perhaps). Initially, this would not be planned, but could be considered later. It was emphasized that iptel shall provide an initial set of reasonable services and leave some hooks to further extend the capabilities.
User interaction was another feature requested for the Call Processing Syntax. Simple user interaction was agreed but not assigned an utmost priority to be included in the first step. This services my require the implementation of a back channel for user interaction in the future.
An execution environment to utilize special services like the possibility to provide a password for a MCU (Multi Conference Unit) was accepted as useful.
As it is a syntax, the issue of language types could become problematic. It was agreed that this is a complex area and later discussions would need to be taken to hash out some of the language questions.
The problem of feature interaction was mentioned. It was agreed this would be tough to deal with, and care would need to be taken.
There was then a brief presentation of the gateway location protocol. It is basically a back end distribution mechanism to allow servers to build up a database of gateways and attributes to assist them in selection of gateways. Some of the requirements for a protocol of this sort are scalability, security, auto-discovery, extensibility, etc.
It was mentioned that guiding a server in gateway selection may be a component of a call processing syntax service. In that case, can call processing syntax development proceed without a better understanding of the gateway location service? It was decided that guiding gateway discovery was a v2 call processing syntax issue, and by then we would have a better understanding.
3. ETSI TIPHON Liaison - Louise Spergel and Gur Kimchi
The presentation of the TIPHON project included an overview, the current status and technical aspects of the TIPHON project.
One of the major comments to the presentation was that documents generated by ETSI are not freely available. The statement of the ETSI representatives was that currently ETSI does not give away documents for free. However, the decision was made to give documents away for free in future. The documents will be distributed on the web.
An other comment from the audience regarding ITU documents was, that H.323 related documents from SG16 are freely available on the web. The web page will be posted on the IPTEL mailing list.
It was agreed that there was synergy between the groups and communication should continue in the future.
4. Presentation on SIEVE - Tim Showalter
The presentation on SIEVE intended to illustrate the issues and design problems involved in developing a scripting language to direct server behavior. Sieve is designed to control email forwarding and filing at a mail server on behalf of a client. It was noted that sieve is still in a BOF stage.
Some of the main issues faced by sieve were how to guarantee termination, dealing with internationalization issues, language completeness, expression matching, and extensibility.
5. ECTF CTI Call Models - Peter Kozdon
Peter Kozdon presented the Enterprise Computer Telephony Forum's (ECTF) call model. This call model defines elements, architectures, and interactions of telephony systems. It can serve for packet and traditional telephony scenarios. Its relevance to iptel is that it defines a framework for telephony services which might be used for the framework document for the call processing syntax.
The audience mentioned that this call model is a basic foundation and can do a lot of things beyond placing calls. However, the Internet is more than audio and video and the capabilities covered by the ECTF call model don't address these. However, the model could serve as a good starting point.
6. Call Processing Syntax Development Efforts - Jonathan Lennox
The presentation covered efforts so far at developing a call processing language. A tcl-like language is being developed. It is based on an event model, allows access to the fields in call invitations and responses, and defines timeout events. The goal of the language is to be signaling-protocol independent if possible, extensible.
Most of the questions raised by the audience surrounded the model behind the syntax. Who is the syntax operating on behalf of? The user? A device, such as a phone or answering machine? Where does it operate? What is the realm of its control? If there are multiple scripts running, how does one reconcile the different results that each may obtain? Are some kind of semantic rules needed to combine them? Why not just implement the syntax as software on the end system and avoid a standard syntax? What kinds of services are available from the language? What kind of interaction with a user is possible?
All of these questions are essentially what is to be addressed by the call processing syntax service framework document. This will describe the overall architecture (answering questions like where are scripts run, who puts them there, etc.), and the services provided by the syntax. From there, the actual syntax can be developed.
It was mentioned that this is a very difficult problem with a potentially unbounded scope; as such, a July completion date for the framework document is unlikely. Scott Bradner indicated that milestone dates evolve as understanding of the problem progresses.
7. Moving Forward - Jonathan Rosenberg
Finally, Jonathan Rosenberg asked the audience to further contribute to the workgroup, especially in the area of frameworks for the call processing syntax. The meeting then concluded.
SIEVE: Language Overview
IPTEL - Agenda and History
Call Processing Languages for Internet Telephony
Call Model Presentation
go to list