NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>
Scott Bradner <sob@harvard.edu>
General Discussion:iptel@lists.bell-labs.com
To Subscribe: iptel-request@lists.bell-labs.com
Archive: http://www.bell-labs.com/mailing-lists/iptel
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 j.doe@bigcompany.com. 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.
Done |
|
Submit gateway location framework document to IESG for consideration as an RFC. |
Done |
|
Submit call processing syntax framework document to IESG for consideration as an RFC. |
Done |
|
Submit call processing syntax document to IESG for consideration as a Proposed Standard. |
Feb 01 |
|
Submit gateway location protocol document to IESG for consideration as an RFC. |
· CPL: A Language for User Control of Internet Telephony Services
RFC |
Status |
Title |
RFC2824 |
Call Processing Language Framework and Requirements | |
RFC2871 |
A Framework for a Gateway Location Protocol |
IPTEL WG
========
CHAIR: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Minutes were taken by Joerg Ott. Edited by Jonathan Rosenberg.
AGENDA:
1. Agenda Bashing [Rosenberg] - 5 mins
2. CPL Status and Update [Rosenberg] - 5 mins
3. TRIP Open Issue [Rosenberg] - 10 mins
4. Transit Network Selection [Walker] - 10 mins
5. TRIP MIB Update and Issues [Walker] - 10 mins
6. Service Codes [Peterson] - 10 mins
7. New Charter discussion [Rosenberg] - 30 mins
CPL Update
----------
- CPL submitted to IESG in November 2000
- end of Dec: IESG reports back concerns
- using a subset of iCalendar can lead to interop problems
- CPL -> tools works
- tools -> CPL does not
- If iCalendar is too big to be implemented, it must be fixed in calsch for all
- calsch group not aware of CPL efforts
- calsch chair, Patricia Egen, agreeds to look at spec
- discussion took off (on calsch list)
- syntax: a few concerns of not using the sntax
-> not considered that big a deal
- only one commendator on use of subset - John Stracke - agrees that iCalendar is too large
- UI can't represent all of ical
- computing and memory requirements are an issue
- agrees to write up subset definition
- subset written by John S. and Jonathan Lennox
- to be discussed this Wednesday
- Proposal
- agree to the proposed ical subset
- re-write CPL spec to reference subset document
- CPL and subset doc go to RFC simultaneously
TRIP Open Issue (Jonathan)
-------------------------
- WG last call ages ago
- comments came up only slowly
- shall be drawn to conclusion quickly
- comment this meeting or this week and then be silent
Issue #1:
- intra-domain topology updates really only need ITADTopology attribute
However, spec mandates WirhdrawnRoutes, ReachableRoutes, and other as mandatory for all messages. These will all be zero length, which is pointless.
- Proposal
- define new message for intradomain topology updates (1)
- remove requirement for all attributes to be present (2)
- Jonathan proposal on the list: remove requirement (2)
Comment: text must say that there needs to be "at least one these elements"
-> consensus: go with (2), modify according to comments
Issue #2: Address families
- decimal
- penta-decimal
E.164 is decimal but can be anything
- what if it is defined as part of a peering agreeemnt?
concern: in practice, handling anything but E.164 is hard
What to do:
a: define an E.164 address family
b: don't define it
Proposal:
- keep things explicit
- define an E.164 address family
Q: w/ this, do we still beed decimal and penta-decimal
-> YES
CONSENSUS also on this one
Transit network selectionm (Dave Walker)
----------------------------------------
draft-walker-iptel-trip-tns-01.txt
- PSTN allows for multiple routes to a destination (e.g. different carriers)
- TNS code indicates preferred carriers (Carried identification code)
- users may pre-subscribe or dial carrier access code
- national identification plans
- ANSI ISUP
- networks respect TNS except for local ermination
IPTEL solution
- users may access both IP and PSTN based carriers
- for IP-based carriers, set the URI accorndingly
- for PSTN-based carriers, IP network must route the call to the right network
- need to distribute "best" route to the specified TN through TRIP
- exactly the same problem as TRIP solves for dialled numbers
This generated a lively discussion. Dave Oran had a concern about using a routing protocool do distribute routes to intermediate carriers. The equivalent would be BGP distributing routes to AS instead of IP addresses. The answer was that as far as the IP network is concerned, these carriers are not intermediaries, but end points (gateways to that carrier). Some argued that Dave's point implied that this was an attribute. Jon Peterson argued for an address family. One issue is whether a carrier can terminate calls to any number. If not, then we need to propagate carrier information and the routes they can reach. It was pointed out that in the US, it is mandatory for a carrier to route to any number. The problem, though, with using TNS as a route attribute is that you don't want the route with the longest prefix; you want to use the route which matches the carrier requested for the call. It was agreed to spawn this to the list. It will not go into the TRIP spec.
TRIP MIB (Dave Walker)
----------------------
- update -04 draft
- initial support for authentication
- aplIndex from network services MIB
- is it needed?
-> proposal from Jonathan: YES
- require generic mechanism for handling?
- new attributes
- new address families
- new protocol families
- security (suport for authentication draft)
- compliance statements (to do)
DW feels that this is very stable. Please, folks, take a closer look at it from your side before we go to last call.
Using Service Codes in SIP (Jon Peterson)
-----------------------------------------
draft-jfp-service-codes-00
investigation on what is necessary in TRIP for service routing experimental work to show requirements
Overview of service codes:
- proposal for attributes associated with propageted routes in TRIP which characterize the service offered by the originator of the route
Why use service codes in TRIP?
- feature interaction among network applications
Basic TRIP service codes
- update (adds service code attr; e.g. LNP)
real strength if TRIP and VoIP protocol interact
- definition of a service code field for the Request URI sip:jo@tzi.de;sc=x
- concept of a feature proxy at which services for a particular route are composed
Feature proxy: conventional 2543 proxy
- acts as outbound server
- acts as location server/registrar
- supports service codes
Henning was concerned about an approach with enumerates application names. Sounds like what telcos do today. Dave Oran was concerned that this would require running arbitrary application programs on a proxy - active networks. Do we want to go there? Henning argued that CPL should be used instead; CPL would direct this feature proxy to send calls wherever you want. Otherwise, voice mail may be code 17 with one provider, 25 with another; may have to update your CPL repeatedly. He argued that services are location independent; what we are doing here is re-inventing SLP on a global scale. Dave pointed out that we may be tripping over the meaning of the word "service".
It was clear that there was a lot of difference of opinion about what was being presented, and what the value was.
New Charter Discussion (JR)
---------------------------
New charter was sent to the list
1. TRIP MIB (proposed)
2. TEIP operational guidelines (BCP)
3. GW registrrations (proposed)
4. (informational)
Not on the charter:
- CPL
- Draft version of TRIP
-> need much more experience first
TRIP MIB
---------
- proposed completion: Dec 01
- based on current TRIP MIB doc
TRIP ops BCP
------------
- most complexities are in usage and policies
- proposed completion: Feb 02
GW Registration
---------------
- draft-rs-trip-gw-01
- proposed completion: Sep 01
VoIP Routing Framework
----------------------
- inter-domain
- intra-domain
- gw registers
- servcie routing
good to document these problems and their requirements
- draft future work on service routing and intra-domain route exchange
starting points: service codes and gw registration as strating points
- completion Sep 01
Other proposals:
tel: URL
--------
- bring to draft standards
- freeephone and LNP extensions
- trunk group ids
- basically -- SS7 extensions
TRIP authentication attribute document
---------------------------------------
- huge problem here; is this needed at all?
- look for a real need first!
Discussion points:
- are these real problems to solve?
- are there people willing to work on?
- commitment to write text!
- shutting down is a *very* acceptable result!
Hennings point was that the TRIP MIB is harmless. The tel URL work needs to be done, since its broken. However, he felt that the other work was not yet working group material, since it was a little premature. Jonathan agreed that there are implementations of TRIP; but there is not yet real deployment.
Dave Oran felt that we need to do the MIB, and we want the gateway registration thing. The service routing work and operational guidelines are to premature. No opinion on the tel URL.
Jon Peterson argued that we should do gateway registration and the tel URL.
Scott Bradner said that there shouldn't be operational guidelines at this point. Gateway registration work is OK, but he is was not clear on why the tel URL work should be here. Service routing was too premature. MIB should get done.
There was some discussion on the tel URL. Scott suggested that a design team, outside of any working group, work on fixing up rfc2806. Henning expressed interest in leading that activity.
Given this input, Jonathan made the following proposal for rechartering:
- GW registration
- TRIP MIB
Now the call for volunteers. We need enough to be able to work on these. We had sufficient people to work on both items.
Group Updates
Using ServiceCodes in SIP
TRIP Transit Network Support
TRIP MIB