2.7.4 IP Telephony (iptel)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 25-Oct-99


Jonathan Rosenberg <jdrosen@dynamicsoft.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:iptel@lists.research.bell-labs.com
To Subscribe: iptel-request@lists.research.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:

Jun 99


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

Aug 99


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

Oct 99


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

Dec 99


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


No Request For Comments

Current Meeting Report

Minutes for the IPTEL (IP Telephony) workgroup meeting

Place: Omni Shoreham Hotel Washington DC
Date: Nov. 08. 1999, from 19:30 - 22:00
Reported By: Wilhelm Wimmreuter, John Truetken
Prepared By: Jonathan Rosenberg

The IPTEL working group session was held on Monday afternoon.


1. Agenda bashing [5 min - Rosenberg]
2. TRIP Framework [5 min - Rosenberg]
3. CPL Framework [20 min - Lennox]
4. TRIP presentation and open issues [10 min]
5. Wrap-up [10 min - Rosenberg]

1. Agenda Bashing

The agenda was accepted

2. TRIP Framework (Telephony Routing over IP),

The chair presented the reasons for renaming the GLP to TRIP. This was the only change from the previous version. However, the change was not made in the figures, so the draft will be resubmitted once more, and than go to IESG. As such, this is the last opportunity to get any comments in.

3. CPL Framework, Jonathan Lennox:

Jonathan Lennox discussed the changes in the CPL framework document from the previous version. This includes additional discussions on handling scripts from multiple users, discussion of script creation and usage, and general reorganization. Discussion was also added on the advantages and disadvantages of using traditional turing complete languages, like Java, in a "sandbox" to introduce safety. Other Changes included the change from "network systems" to "signaling servers" and the change from "network model" to "interaction model". Jonathan pointed out that the main open issue is how to decide where to upload scripts, but that this was not a major hurdle to solve.

Jiri Kuthan then raised the issue of whether a more powerful language should be defined, and to leave it to the service buyer to get the script right. He suggested that we should discuss business models of CPL usage to help get this right. The chair objected, stating that IETF does not discuss business models. CPL provides a service; if you don't want it, don't use it.

Scott Petrack asked about the status of a document from two meetings ago on how to upload CPL scripts in the SIP REGISTER method. Jonathan R. answered that the iptel group had reached consensus specific transport methods would be done in other groups. For example, if SIP is proposed as a transport for CPL, this would be done in the SIP group. If http were to be used, the work would be done in the http group. Jonathan L. was encouraged to resubmit the draft to the sip group.

James Kempf asked how a UA would know what server to send a CPL script to? Can it be more than one? The answer is that there is choice in selecting a server. Some people now are using DHCP to get the nearest, but there are cases where picking one depends on some service characteristic. In that case, defining a service template for SLP for SIP servers might be a neat idea.

Jonathan R. then issued a wg last call on the CPL framework. The last call was for 2.5 weeks. At that point, if there are no revisions, the framework will be sent to IESG for informational.

4. TRIP presentation and open issues,
Matt Squire, Hussein Salama, and Jonathan Rosenberg

Matt Squire

Matt Squire began with the security open issues. BGP currently has an authentication header, but there are no specified or used authentication algorithms There is also an RFC on using a TCP MD5 checksum, but this has known security holes. IPSEC and/or TLS can also be used. There is also some new work on defining nested signatures for path attributes. This allows each provider on the path to sign an attribute, so that the recipient can verify each hops ontribution. However, this interferes with aggregation.

So, the question is: what to do? We clearly need peer to peer authentication. Dave Oran, wearing his IESG hat, emphasized that the protocol must allow every implementation to run in a secure mode. He also emphasized that we should allow TRIP to use different keys than other applications between the same pair of hosts. The issue, however, is whether to mandate a specific security mechanism (IPSEC or transport layer), or allow both. Dave pointed out that interoperability is best achieved by choosing one.

Regarding next hop authentication, Matt indicated he thought it useful to have at least next hop authentication, to verify that an entity that changed the next hop and associated attributes is who they say they are. This is different from peer to peer authentication when the peer doesn't change the next hop. It was pointed out that this was basically the same as nested authentication, except with a single layer of nesting.

Christian Huitema spoke in favor of signatures, as they help to double-check the information that is provided to you. This can check cases where a peer has been subverted by an attacker.

Dave Oran suggested that we take this to the list, and should talk to experienced BGP security experts to get some input.

With that, Matt moved on to the next related issue. BGP defines a marker field, which seems to have no purpose beyond authentication. So, if we are not using the BGP authentication framework, do we need this? Matt asked for input from the group.

The next issue, and the largest open issue in TRIP, is the intra-domain synchronization. Matt first explains how flooding works, and then pointed out that there are synchronization issues with withdrawals. These relate to the problem of wrapping sequence numbers. Without the assumption of non-wrapping sequence numbers, we need to use acknowledgements and add some additional semantics to the protocol. Both Christian and Dave Oran suggest that we should just use non-wrapping sequence numbers. Matt indicated that private discussions with the other TRIP co-authors had come to the same conclusion more or less. Dave suggested actually using the IS-IS mechanism, as it is well tested and has been proven correct.

Hussein Salama

Matt then passed the mike to Hussein, who started with his proposal for an alternate synchronization mechanism. The basic idea is that instead of maintaining a CRIB for each internal LS, each LS would maintain just one for each connected peer. This would be accomplished by not flooding routes that are not accepted. The chair clarified that the big idea was to use the same mechanism used in E-BGP for the intra-domain synchronization. So long as (1) each LS within an ITAD has the same policy, and (2) the decision process always assigns preferences to routes, and selects one, independent of the existence of other routes, it can be demonstrated that each LS will converge to the same Loc-CRIB.

Dave Oran indicated that he wants to make sure we don't violate the BGP "barrier" feature, whereby changes in intra-domain topology do not get exposed in the exterior routing protocol. Peter Flien raised the issue of how this proposal affects fault tolerance and route flaps. Jonathan R. answered that even in current interior routing protocols, like OSPF, there can be periods of inconsistency inside. The trick is a hold down timer which doesn't propagate the information until its stabilized. It was recognized by the TRIP authors that Hussein's proposal would increase the time it takes for routes to stabilize (Hussein presented a specific example to illustrate this), and thus we would need to increase this timer, although we don't know how. The proposal would also add more route flaps.

Matt went on to the next issue, which is separation of application layer protocols (i.e., SIP and H.323). There are three approaches:

David Oran indicated that the latency and overhead issues are an implementation issue.

Jim Luciani indicated that based on SCSP experience, each advertisement received should be for a single protocol. Jonathan R. indicated that each advertisement adds a route for a single protocol, but might withdraw routes from other protocols. Jim indicated that this would be fine. There seemed consensus for this, which is what we have now.

Joerg Ott indicated that if the attributes were shared across routes for different protocols, update volumes could be reduced by not having to send two separate routes. Jonathan R. indicated he doubted this would be common, as next hop (including port number) is an attribute, and H.323 gatekeepers and SIP servers will usually run on different ports, likely on different machines.

Hussein then raised an issue discussed at the last IETF, of separating H.323 into H.323 Q.931 and H.323 RAS. He wanted to do this in order to support load balancing of RAS among gatekeepers. Joerg has concerns about this, since LRQs aren't supposed to cross domain boundaries.

Another open issue is how the message is structured. The current proposal is that everything is an attribute, and that attributes MUST appear in ascending order of value in order to ensure grouping of data. This in contrast to BGP which has specific fields for withdrawn routes and new routes. The question was: is this OK? It seemed to be OK, but additional clarification is needed in the document on this.

The final open issue discussed by Hussein was multiple TRIP identifiers. Should we allow a machine to support multiple virtual TRIP speakers each with a different identifier? No consensus on this.

Jonathan Rosenberg

Hussein then handed the mike to Jonathan. The first issue is capabilities. TRIP supports general capabilities negotiation. Right now, there is one capability, which is type of routes supported. This includes the application layer protocol and addressing scheme (SIP and E.164, for example), and the address format for the next hop (IPv6, for example). The question is: are there other capabilities? Since we can always add others later, there seemed to be consensus to just stick with that now.

Another open issue is the "BGP community attribute" defined in RFC1997. Its a general policy tool. Since its not hard to specify, and known useful, there seemed to be consensus to stick it in.

Another open issue is on ISUP flavors. The issue is that if SIP-T is used, and *if* SIP proxies perform flavor translation, they may want to select next hops based on ISUP flavor support. However, we don't yet know whether we will need this. Christian felt that you should only send ISUP where you know it will be understood. As such, there seemed to be consensus not to include ISUP flavor attributes in the TRIP protocol.

Finally, Jonathan R. indicated that pricing and capacity have been taken out of the main TRIP spec in order to advance it. Editors for these documents who are interested in progressing the work should contact the chair.

At this point, general questions and comments were taken. One issue was raised on traps and notifications of route failures. For example, if a flap causes there to be a time during which no route to some prefix is available, how does this get propagated? The chair indicated that this is not an issue for TRIP itself, but perhaps for a MIB for a Location Server.

Another issue that was raised by Dean Willis was on the choice of 16 bits for the ITAD identifier. Dean's concern was that this limits the number of providers to 64k, which may not be sufficient. The chair agreed, and suggested 32 bits. Christian expressed concerns about this as well. Related to that, if we are not using AS numbers for ITADs (there was consensus NOT to use AS numbers for ITADs), we will need to set up an entire process for ITAD number administration. Rather than doing this, it was suggested to use domain names, or perhaps even a UUID, as an ITAD number. It might be long, but will avoid the need for additional administration which can hamper deployment.

Finally, the issue of whether RoutedPath is mandatory or optional was raised by Reinaldo Penno. Right now its mandatory, but liste as an open issue. Reinaldo emphasized that he wants to keep it mandatory.

5. Wrap up

Jonathan Rosenberg concludes the meting and asks the attendees again to contribute on "Pricing & Capacity" attribues.


None received.