2.8.6 IP Telephony (iptel)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01


J Rosenberg <jdrosen@dynamicsoft.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@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:

The focus of the IP Telephony (iptel) group is on the problems related to propagation of routing information for VoIP protocols. Specifically, both SIP and H.323 have the notion of signaling intermediaries (proxies in SIP and gatekeepers in H.323). When these devices receive call establishment messages, they must make a routing decision on where to forward the call setup messages.

The iptel group has already defined a protocol, Telephony Routing over IP (TRIP), which solves one aspect of this problem. Specifically, it handles the case where calls need to be routed between domains. It allows for the exchange of routing information between these providers, so that policies can be applied to the resulting data to create a forwarding information base.

However, this protocol does not address all the scenarios of route information exchange between servers. One important scenario is the propagation of routing information between gateways and the signaling servers in front of them. This is also known as "gateway registration". It allows the signaling server to make a routing decision about which gateway to use based on dynamic information about the gateway resources. Vendors have deployed proprietary solutions for this communications interface. A standard is needed. The group will generate a standards track document that defines a protocol (possibly based on TRIP) for this interface.

The group will also generate a MIB document for TRIP.

Note that the group is not working on elevating TRIP to Draft Standard at this time.


1. A proposed standard RFC for gateway to server route exchange.

2. A proposed standard TRIP MIB specification, based heavily on the existing BGP-4 MIB documents.

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.



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

Apr 01


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

Sep 01


TRIP MIB Document submitted to IESG for consideration as proposed standard

Jan 02


Gateway to Server Route Exchange document submitted to IESG for consideration as proposed standard.

Request For Comments:






Call Processing Language Framework and Requirements



A Framework for a Gateway Location Protocol

Current Meeting Report

Minutes of the IP Telephony (iptel) Working Group IETF 51
Minutes taken by: Mary Barnes
Minutes prepared by: Jonathan Rosenberg

The IP telephony (iptel) group met for a single, one hour session at IETF 51. The proposed agenda was:

Agenda Bashing 5m
CPL and TRIP Status 5m
Charter Review 10m
TRIP for GW 10m

The agenda was agreed upon.

First up was a status update on TRIP and CPL. CPL is still blocked on calsch issues. Scott Bradner indicated that he is hoping to get this resolved finally. TRIP has been going through the IESG, with minor comments getting incorporated. Scott indicated that IESG has, in fact, approved TRIP for RFC.

The new charter is presented. There are two items, a TRIP MIB, due in September 01, and "TRIP for gateways", also known as "TRIP-lite", due to IESG Jan 02.

Next, is a discussion on the changes to the gateway registration draft since the last iteration. These changes are:

* Explicit requirements defined
* Comparison with existing protocols
* Inclusion of open issues
* Removed DSP Capacity

DSP capacity was removed because its not clear how to use it, and can be factored into the circuit capacity attribute. Concerns are raised about its removal. Dave Oran made some arguments that the meaning of the parameter wasn't important, so long as its statistics had specific value. The chair indicated that unless it was well documented and described, it would result in vendor tie-in between gateway and proxy. Dave agreed to provide some more detailed definitions.

Next up, we discuss the requirements for the trip for gateways protocol, in general terms:

1. Fast call setup

2. Conveys failures of gateways rapidly

3. Conveys restarts of gateways rapidly

4. Proxy has some way to know available capacity

5. Security: mutual authentication and integrity. Privacy less critical.

6. Convey routing preferences

7. Timeliness of attribute information

8. Extensible attributes

9. Efficient

10. Centralization of policy (Proxy server in front of the gateways ultimately makes the decision on how the call is routed)

11. Proxies in ITAD make independent policy decisions.

Henning objects to requirement 5, stating that mutual authentication isn't needed. He claims its at odds with privacy. The reason is that Henning has a somewhat different model in mind. He is interested in an enterprise problem, where a proxy dynamically discovers the gateways it can route calls to. As such, mutual auth is a pain since its more of an advertisement protocol. As such, Henning wants to add auto-configuration as a requirement. Jonathan argues that this complicates policy, since its hard to define policy over managing gateways that you only later discover. Henning argues that this is not true - since the gateways may go up or crash, there is already a need for policy which handles the case where the number of gateways varies.

Next, Jonathan asks whether auto-discovery a requirement or not?

Some argue that this is needed anyway for scalability and reliability. Dave asks who is discovering who? Are gateways discovering proxies, or the other way around? There is some debate about this. Jonathan proposes that we make autodiscovery orthogonal to TRIP - i.e., discover it somehow, then use TRIP-lite between them. Henning objects to that also, since he doesn't want three protocols where one will do. He indicates that the question is whether existing protocols meet all of the requirements or not. Jon Peterson asks about whether we are talking about auto-configuration or auto-discovery - ie., are RIBs generated automatically from the combination of policy + TRIBs? Jonathan indicates that this is not what we are talking about, and that this is an interesting question but for later work.

The consensus of the room is that auto-discovery is not a bad thing, but still not clear its needed.

Next, Jonathan presents the analysis of existing solutions. The focus is on SLP, and he argues that there are two cases. In case 1, the gateway is an SLP SA, and the proxy is a DA. In case 2, the gateway is an SLP SA, and the proxy is a UA (there is no DA). Jonathan argues that case 2 is bad, since it introduces delay and makes centralization of policy hard. Henning argues that the UA can cache the service replies. The reply is that service announcements had lifetimes, not the service replies. He said that no, the service replies can remain active without requerying. Jonathan argued that this is basically approach 1, which makes more sense.

Rohan Mahy expresses concern about a terminology problem. Is a proxy the same as LS in these discussions? The answer is yes, and that Jonathan has been lazy with terminology. The proxy = the LS that is managing the gateways.

Henning argues that the intra-domain problem is much different than inter-domain, and that something like SLP is more appropriate intra-domain. SLP is done already, and does autodiscovery and propagation of attributes. Its also simpler, since TRIP is a very complex protocol. Jonathan asks what aspects of TRIP are more than you need, and would not be present in an SLP protocol. Henning responds that you don't need the transition of information into an inter-domain protocol, since there may not be one running. Jonathan argues that this is not a technical objection per se, since there is no cost to that aspect of TRIP. The question is: if you use TRIP instead of SLP, what features do you need to implement that otherwise wouldn't be needed (i.e., are there because of the "legacy" TRIP usage). It wasn't clear what those things were. Jonathan argued with Henning that both TRIP and SLP "exist", so arguing about using an "existing" protocol is moot in this case.

In order to move forward, the chair imposes the following decision:

1. we will have an open call for concrete, written up proposals in Internet Drafts form, which must be received by September 7 (one month from the meeting date). If there are no concrete proposals for SLP or anything else, we will move forward with the current proposal. We have tight deadlines and they need to be met. The proposals must outline concrete things in the current proposal which are not needed, but must be implemented because of "legacy" usage. Only concrete technical statements will be accepted. Things like "too complex" or "won't scale" are not acceptable.

2. requirements are critical for evaluation of the proposals. Please contribute requirements to the list for discussion.

With that, the meeting closes.