2.7.6 IP Telephony (iptel)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00


Jonathan Rosenberg <jdrosen@dynamicsoft.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:iptel@lists.bell-labs.com
To Subscribe: iptel-request@lists.bell-labs.com
Archive: http://www.bell-labs.com/mailing-lists/iptel

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

Goals and Milestones:



Submit gateway location framework document to IESG for consideration as an RFC.



Submit call processing syntax framework document to IESG for consideration as an RFC.

Aug 00


Submit call processing syntax document to IESG for consideration as a Proposed Standard.

Aug 00


Submit gateway location protocol document to IESG for consideration as an RFC.


Request For Comments:






Call Processing Language Framework and Requirements



A Framework for a Gateway Location Protocol

Current Meeting Report

IPTel WG Meeting, IETF 49, Mon, 11 Dec 2000 09:00:00 PST

Chair: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Notetakers: Jonathan Lennox <lennox@cs.columbia.edu>
Steven Donovan <sdonovan@dynamicsoft.com>

Jonathan Rosenberg: Agenda

Agenda bashing [Rosenberg] 5 min
Working group update [Rosenberg] 5 mins
Service codes [Peterson] 15 mins
TRIP MIB [Walker] 15 mins
Intra-domain architecture [Rosenberg] 15 minutes
CPL Authorization [Kuthan] 15 mins
Working group future directions [rosenberg] 30 mins

Jonathan Rosenberg: WG update

* CPL specification
- draft -03 iesg last call made nov 17
- under AD review now
- interop testing done at last SIP bakeoff!
- CPLs created by indigo tool sent and processed by dynamicsoft interpreter
- Round of applause for Jonathan Lennox's hard work on this one

* TRIP Specification
- WG last call issued on draft -04 on Nov 29
- Authentication stuff removed, since Hop-by-Hop using IPSec seems to work fine for us for now
- last call ends after IETF

Jon Peterson: The ServiceCode Attribute for TRIP

Overview of ServiceCodes
* Add an attribute to propagated routes that characterizes the service offered by the originator
- Makes routes more specific
* Largely for intradomain use, but not exclusively

* Why use ServiceCodes?
- Feature interaction
- Differeniation of types of termination
- Operations & Management simplified
- Aggregation gains sophistication


Two servers, one of which is an app server that provides some kind of LNP service for the +17208883 prefix, and another which is a gateway for +1720. Both use TRIP to propagate routes to these prefixes to the proxy server. Now, when a call comes, which route is used by the proxy? Its not necessarily longest prefix; it depends on the type of service. For example, you want to apply LNP before routing, so you would send to the app server first.

Jonathan R. then provided a clarification: implicit in TRIP model that what's propagated is routes to one very specific service: gateway; but we could route to lots of different things. In picture: we have two different things. What happens when we add routes to more different kinds of things? That's the problem Jon's solving.

Jon commented that service codes were useful even for just gateways, since there are lots of different types (ss7 gateways, analog, etc.).

Proposal: service codes -- in example, LNP for App Server, SS7 Termination for GW. LS propagates both, doesn't aggregate them -- two routes propagated

Operation problem: administrator can snoop TRIP packets and figure out what's going on

ServiceCode assumptions:
* LS provisions call routing agents (PS) based on received routes
* Policy matrix in the LS could use SCs to determine precedence of received routes
* TRIP environemnt in which applications register dynamically (and sometimes compete with one another)

Examples of ServiceCodes
* PRI Termination
* Freephone Translation
* Conferencing

IANA Registration of ServiceCodes
* Maybe families of ServiceCodes
* Default -- Unspecified Termination
- For backwads compatibility

James Kempf indicated that we should be sure to look at rfc2609, which defines a syntax for services that we could use here, rather than reinventing our own.

Jon then continued his presentation. He gave an example where an App server has many applications, and has propogated routes associated with all these apps to proxy server. Today, proxy server has to make decision as to what application to run on call. If it forwards the request to the app server, how does it tell that app server which application to run? Should we extend SIP to include ServiceCode in INVITE?

Jonathan indicated that he didn't think this requires an extension to SIP. The App-components draft discusses these kinds of issues. Request-URI in SIP points to a resource, resource can be anything. URI is user@host; define conventions as to how you structure 'user' part for services.

Jonathan also discussed SLP. He wants to make sure we're not reinventing SLP. He thinks we're solving a different problem, but the group has to make sure we understand how it's different -- we should write an I-D on this. Even if they are different, they can work together.

Jon discussed inter-domain usage. Service codes can be used between ITADs to defined policies. For example, ITAD2 wants to block services related to unified messaging.

There were no further comments from the group. Jonathan indicated that we will talk about what to do with this work towards the end of the meeting.

Dave Walker: TRIP MIB

Dave Walker couldn't make it, so the MIB draft was presented by David

Why a MIB?
* Not required in the charter...essential for management
* Completes the system view of a device

Based on RFC 1657, the BGP4 MIB, since TRIP is like BGP4.

What's in it?
* Configuration and statistics for local entity and peer table
* Default peer configuration
* A routing table containing adj-TRIB-ins from all peers
* A couple of Notifications

What it counts
* Peer updates
* Peer messages
* Peer FSM transitions

TRIP Peer Table Entry
Some object in the peer table
(List of attributes: see slide)

Routing Table Entry
Some objects in the routing entry are: (List of objects: see slide)
Last is boolean: is this route the best chosen route?

ITAD Toplogy
ITAD Topology Table objects, Topology ID

To Do:
syncrhonize with TRIP -04 draft
compliance statements
trip for gateways
new attributes
new address families
new protocol families
use rfc 2851 reference for internet addresses

David asked if we need a mailing list. Jonathan R. advised to keep on the main list for now.

Jonathan indicated that a MIB not necessary for proposed standard, but is necessary for draft; encourage the group to charter the group for a MIB. Doubt there'll be much controversy over this.

Jonathan R.: Intra-domain architecure

Jonathan discussed the meaning of "intra-domain architectures", which has generated a fair amount of debate on the list.

He said we did inter-domain first; effectively solving the problems in the reverse order of importance. Arguably intra-domain is more important. He proposed that we've already solved this problem too; VoIP routing is different from Layer 3 routing in the intra-domain. In IP, decision point is to find shortest path, only. That's what Layer 3 routing is good at. In VoIP, routes amongst proxies within a domain are still dependent on policy. This is the primary reason why we care where packets go to. If we just want shortest path routing, just use layer 3 -- number of proxies is 0. Use proxies for management & policy of resources. Not about least-cost routing.

Example Network: 1 ITAD -- Termination provider. Terminates phone numbers. NY Pop, CA Pop. Each pop has gateways, some load balancing proxies in front of them. The NY POP has another layer of proxies to manage the many terminations in NY. THere are also customer facing proxies. Calls from customers arrive there first, and are authenticated.

The ITAD policy is +1212 to NY, +1415 to CA, each backs up the other in case of failure. If NY goes down, route through California. But shortest proxy-POP path to NY is through CA, since there is one less layer of proxies there. This is wrong. Could just set weights on the routes, but this is horrendous to manage. If I add a single proxy server, could change entire weight structure.

Policy should be that customer-facing proxies determine how calls should be routed to the POPs. Proxies in POPS determine which gateway farms to forward calls to. Load balancing proxies in each farm figure out which gateway to use. Effectively, each proxy determines routing using data about its peers coupled with its local policy objectives.

Architectural model: Group of proxies within a domain look like their own mini-domain! Makes sense to use trip for intra-mini-domains.

what needs to change in TRIP to support this?
- additional params and attributes
- gateway capacity, codecs, local preferences, etc. These things were eliminated from the inter-domain protocol; but they may make sense within a domain.

James Kempf commented - maybe also SLP? He argued that we need pull technology to have more control over proxies? Need input from Service Providers as to how they want to build their networks. Jonathan argued that here, a push model was more appropriate. This is because, unlike normal SLP, the number of "clients" asking for resources from a gateway or proxy is small and enumerable. This means you can establish trust relationships ahead of time, and just exchange data over those connections. Thus, its more like a push oriented routing protocol than a pull oriented client-server query protocol.

Rohan Mahy wanted to clarify that when we leave the domain, we filter out all these intra-domain attributes. Jonathan said yes.

Open issue:
Is last hop from gateway to proxies that front it a push or pull protocol?
* push:
- faster
- better for policy
- security model makes more sense
- ideal for point to point case
* Pull
- good for large fan outs
- allows gateways to be used by any type of client

Argument is "sort-of" SLP vs. TRIP. In this case, pre-arranged uses of service, small number of clients, pre-arranged, long-lived relationships. More like TRIP than SLP - push rather than pull. A draft needs to be prepared on this subject.

Big picture: intra-domain looks like inter-domain. Need to do architectural model before designing protocol.

The question was asked about propagation of these new attributes within a domain. Jonathan answered that we would have recommendations, just as we do now for existing attributes. But this is a matter of local policy; let docments defining them give recommendations, but leave it up to service providers.

The question was asked as to whether we should define intra-domain aggregation? Jonathan answered that TRIP already does this; define for each attribute how it's aggregated. TRIP is good at this.

If you have comments on TRIP, we're in WG last call. Raise issues now? (None.)

Jiri Kuthan: CPL Extensions

* Authentication
* Access to external databases
* Next steps?

#1: Authentication support
* Need to make call processing dependent on authentication information
* Example: you may want to relay calls to your cell phone only if originated by those in possession of valid credentials
* Solution: add authentication switching to CPL

Example: <auth-switch>. Don't insist on this syntax.

Current status:
* Consensus on:
- Need for authentication switching
- The need to abstract from speciic authentication mechanisms
* Unresolved issues:
- On what information should be switched?
o Resulting authentication satus
o Authentication ID
o Authentication mechanism class
- Should we develop support for portable credential databases?
o Useful to retain portability fo CPL scripts using authentcation switching.
o If so, the consensus is to separate them from CPL scripts!

James Kempf suggested avoiding defining a portable credential database. Dependent on network you're using, different for different protocols (IS-95, GSM). Better to have abstract interface.

Jonathan indicated that it as not clear that carrying authentication information and passwords is the domain of this group. Security people may already have solutions. I think IS-95, GSM are lower level, though.

Someone else commented that they didn't think there was any consensus that this was required.

Jonathan indicated that there's consensus not to carry credentials. There's consensus that an authentication-switch is needed. However, he commented that for end-users, switching on the authorization strength (i.e., public vs. private key) are not useful, since end users won't be able to make such determinations. Whereas something like authentication status is useful ("are they who they say they are?")
Perhaps realm?

Other issue: external, read-only, database access
* Want to check a header field against a potentially huge list of values maintaind by a third party
* Example: check From field against a list of well-known spam sources.

* Solution 1: Route the call through the site maintaining the anti-spam list
* Soltuion 2: Query the anti-spam list if a caller is on the list.
- Better privacy -- the anti-spam site sees no signaling
- Explicit support in CPL needed.

Difference is how much signalling you send to anti-spam site.

Status: no conclusion on the mailing list.

Next Steps:
* Authentication
- Reach consensus on unresolved issues: (credentials, on what should be switched)
- Generate syntax (switch, responses)
* ? External Database Access

Jonathan Rosenberg: Working Group future directions

All the drafts discussed today are not in the charter
Is there an A-D in the room? (No.)

WG Future:
* Current chartered items are complete. Not the fastest, but good -- we finished.
* We need to shut down or re-charter
* What might we work on?
- TRIP MIB (needed for draft)
- Intra-domain architectures and protocol; gateway registration, service routing (taking TRIP beyond its current space)
- CPL-NG -- extensions within its original problem space; extensions extending its scope (end systems, administrators). Would first need requirements document.

Want to hear from people what problems we want to solve. Want to hear from people. Vendors, service providers: what problems do you want solved?

* do TRIP MIB.
* extend TRIP for intra-domain and service routing. (Can't agree to do it now; need concrete charter and wording)

Hussein commented that he also wanted to charter a TRIP usage guidelines document; how you'd use TRIP and configure policies.

Jonathan clarified what such a document means (it had been discussed amongst the TRIP authors). Today, using BGP is a black art. Not because of the protocol, but because of how you configure policies. Not well documented in IP routing space (maybe on purpose?) For TRIP, how do I set up my policies? E.g. there are prefixes that aren't in use. Concrete issue: we have a notion of multiple address families (hexadecimal, pots). INVITE comes: which table do you look at? addresses overlap...adding more families too. Have to be careful about how you configure the proxy. Well-understood, but not documented in TRIP spec. Proposal is to come up with guidelines for this. BCP or Informational.

Hal Boltz mentioned the issue of emergency communications. TRIP could play a role in supporting these kind of activities -- disaster recovery from hurricanes, earthquakes. Working Group being chartered for this. Jonathan responded that any new WG should toss requirements or usage recommendations "over the wall" to iptel for discussion. Jonathan invited people in iptel to participate in the ieps discussion, and asked if there was a list. Hal responded that there was: www.iepscheme.net; ml and documents.

Jonathan then asked the group about CPL. Do we want to continue to evolve CPL? If we move additional work forward, do we first revisit the model (admin, end systems)?

(Various threats to get people to talk)

Jiri Kuthan expressed an interest to address end devices. Want to
port services between phones.

Someone else from the mike commented that there's not much interest in H.323 in CPL; is it worth focusing on SIP? Jonathan said that there was an ITU liaison statement; there seems to be interest. Jonathan asked if any ITU people were in the room to comment. Joerg said that they're looking at this, but they can't give current status. Jonathan commented that its not ours to work on. If people want to bring 323 things forward, do so.

Rohan Mahy commented that right now CPL is for handling calls as they arrive. Want to make division between that and media termination (voiceXML space).

Jonathan responded that CPL lives in device like a SIP proxy server; most services can be stateless. Some must be transaction-stateful, but none call-stateful. This is nice. Examples of newer services that live in this speace are presence-based routing. There are other devices that you don't want to call a proxy server. Application servers, for example. These are usually call-stateful, and can hang up call, etc, but still no media. Then there are media services.

Jonathan Lennox commented that perhaps CPL can hand off to VoiceXML; inter-work them (maybe one XML document, maybe not).

Jonathan commented that moving towards media level processing was treading on dangerous ground, in relation to other groups. The issue, however, of the play between call control (ala CPL), and media control (ala VoiceXML) was an important one, and a very big one, but much more thinking needs to happen. Lots of folks working on that space. VoiceXML has a bit of call control. Lots of people interested in doing more. CPL is other extreme. Interest in this problem. However, monstrous can of worms; more a research issue.

Someone asked if CPL is a general services architecture? Jonathan said no. Explicitly narrowly focused. See framework RFC.

Scott Bradner (AD) enters room. Jonathan asks "What do you think about working group re-chartering?"

Scott: sign of success in IETF is that WG ends; no a prioriori reason to continue. That doesn't mean there's a prejudice against good ideas.

Jonathan responded that people are already working on next things; question is if it should be in this group. Could charter for specific little things that people are currently doing; but could we charter for additional groups of extensions?

Scott: Related process question: are these of sufficient magnitude to require discussion at multiple IETFs, or is the ML sufficient? ML can continue even if don't meet at IETF. (Meeting space is tight.)

Jonathan responded that authentication-switch could just be ML; intra-domain and service are bigger; MIB is in middle (doesn't get much discussion at meeting regardless).

Jonathan says he's not proposing a charter here; don't have one, and need to discuss with ADs.

Jonathan then asked for hums on interest on working on various topics, to gauge how to (or if) to formulate a new charter for iptel.

Issue Hum volume
TRIP MIB Hum. (Very half-hearted hum.)

Scott commented that this is not a choice, need a MIB. Don't necessarily need a WG charter.

intra-domain good hum
Waste of time? No hum.

Service routing?
(This is fantastically important!, says the chair in an unbiased way :) ) medium hum

CPL for end systems? (Lower-level hums.)

CPL in servers, broaden scope? (similarly low)

CPL for administrators? (similarly low)

CPL media interaction (almost none.)

CPL MIB? What does this mean? Maybe CPL interpreter MIB?
Scott: IESG likes MIBs but we're not compulsive. No Fortran MIB.

Jonathan said his take was the following: the group is interested in taking TRIP to next level. CPL a bit less interest, maybe doesn't need to be chartered item.

Meeting adjourned.


CPL Extensions
The ServiceCode Attribute for TRIP