2.6.5 IP Telephony (iptel)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-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

Minutes taken by: Flemming Andreasen
Hussein Salama
Minutes Edited by: Jonathan Rosenberg

IPTEL met for a single 2.5 hour session during IETF 48 in Pittsburgh.


CPL Open Issues

Jonathan started by describing the changes in revision 2 of the CPL
specification. THe main changes were:


Time handling was the biggest change:

Jonathan expressed concerns about complexity - was it really worth it?
He asked for pseudo-code implementation to see implementation feasibility and ambiguity. Are there translation problems between formats (e.g. calendar to iCal). Long term we probably need the capabilities it provides us with, but really need to implement and see that it works unambigously. Don't want to have lots of different formats (SDP, iCAL, something else)

Further time change: time zones.

Time zones also derived from 2445.
Time-switch nodes have two new attributes:

<time-switch= tzid="America/New-York" tzurl="http://tz.example.com/America/New-York">

VTIMEZONE is basically the same (semantic) rules as new time definition Work is (slowly) in progress to create an IANA iCal timezone registry based on the Olson TZ database.

Jonathan Rosenberg (JR): Is this (iCal) really going to happen ? Real problem that people in different tz. wants to upload CPL scripts and if iCal doesn't happen we then don't have nothing. Henning Schulzrinne (HS): We don't have anything else realistically. Even Windows uses something similar.

JR: There needs to be pseudo-code to show how to do this. If we get that, then we will continue with this proposal.

JR: As for timezone, sync up with iCal people - we need something that works now (consensus on this)

Another change: H.323 bindings: address types

Orit Levin: Complicated issue in H.323 (there are other compl. issues in H.323 as well). Shouldn't this be done in conjunction with the H.323 community.

Jonathan Lennox (JL): Tried doing it on the list.

Orit: Annex O work to begin in SG-16 in two weeks (looking at Internet). Should submit this to SG-16 and ask for feedback.

JR: Prepare a list of questions to SG-16, give to Orit for resolution.

Specific H.323 mappings

OL: Once you have H.323 URLs, why would you want to take the URL apart and map into different address subfields

JL: Because we still have the old stuff around.

OL: Some more comments about mapping concern between H.323 and SIP (addresses and messages)

OL: SG-16 should talk about how to use H.323 with CPL (better qualified)

JL: Agreed that there should be joint work here. If ITU wants to help then fine; we have been asking for their input for a while.

It was agreed that we would not hold up CPL waiting for the H.323v4 or H.323 URL work. Scott confirmed that a proposed RFC cannot have normative references even to other standards work that is not complete. So, H.323 URL and other newer stuff will be relegated into an optional appendix.

Another change: Mime Registration

Added MIME registration section
Media type application/cpl+xml

Conforms to format of XML types in draft-murata-xml-06.txt.

Another change: Parameters, considereations, file extensions

Specified XML public identifier "-//IETF

Specified XML namespace
"http://www.ietf.orginternet-drafts/draft-ietf/iptel-cpl-02.txt" to be "http://www.rfc-editor.org/rfc/rfcxxxx.txt" when we go to RFC

New string-switch fields

New string-switch field: language. This is the language caller wants to receive.

display-field: corresponds to Q.931 display IE

Changes to location nodes

Documented attribute clear of location and lookup nodes.

changes to proxy and reidirect nodes

added output redirection to proxy nodes

Other changes

Todo and proposed enhancements

HS: So where are we ? Ongoing implementations, not a lot ofoperational experience, let people go home and code. Recommend be last IETF presentation before Last Call. May not be the final answer for CPL, but should suffice for version 1.0

HS: Related work: currently non-overlapping, but may change: Voice-XML. Two concepts from vXML to look at (didn't catch what they were, variables (?) ).

JR: Agreed. Fix up the H.323 and timezone stuff. No more presentations. Namespaces allow us to add stuff later.

OL: Who is going to implement the H.323 stuff and verify it.

JR: We can leave it in there. If nobody implements, then can remove before going go Draft Standard. Soliciting input from H.323 community, have done for 1+ year, continue to do, don't know what more we can do.

OL: What if it turns out that changes are needed to be suitable for H.323

JR: We'll have to see what the outcome is.

Scott Bradner (SB): Can always modify and recycle as Proposed Standard if changes needed

JR: Better to get it before going to Proposed.

HS: Let's set a deadline for people to move forward

JL: what about H.323 URLs

SB: can't be a normative reference if still not a standard (H.323v4). Move reference to an appendix. Can always move back when H.323v4 solid.

TRIP Open Issues
Hussein Salama

Hussein Salama prsented the recent changes and Open Issues for TRIP.

Next Hop Server Format

JR: Do what SIP does for transport; for IPv6, there is an rfc that defines the representation of IPv6 inside of URLs, which works for us.


Communities Membership Capability
Based on BGP communities
Permits an LS (Location Server) to announce to its peer the communities it is interested in. The peer then only advertises to the LS routes of those communities.

Attribute Type Codes
Assigned type codes to all attributes.
IANA considerations.
Reserved type codes 224 to ?

Application Protocols
Added two new apl. protocols RAS and H.323 Annex G.

Address Families
Letters other than 10 digits used in Europe.
Had to deviate from IANA's standard set of address families.
Define two address families

IANA considerations
May want to deifne other address families in the future, e.g. URL.

ITAD numbers
Reserved ITAD numbers 0 and 65535
ITAD numbers 64512 to 65534 are for private use
IANA considerations
Proposal: Use domain names instead of ITAD numbers. Issues:

SB: Running into trouble with 16-bit fields for AS. Change to something bigger for ITAD.

MED and Tie Breaking Rules
Removed inconsistency

Secuurity considerations
Protection of peer sessions using IPSec

Protect route itself over multiple hops:

UPDATE Rate Limiting
not yet updated (Adelaide issue - check)

Application Protocol Manipulation
ex: receive SIP route, want to advertise as Q.931 route. Not manipulating an attribute, really chaning the route, not really comfortable with this, what could be the possible side-effects be ?

JR: Difference between this and TRIP is that TRIP is an app protocol

Jon Peterson: Concern about feature transparency loss due to translation (wouldn't be visible from routing info).

JR: Maybe there's another attribute needed to signal whether transparency loss may result.

Hussein: Could add an attibute similar to what we do for route aggregation

JR: OK, consensus is to add that to the spec.

Multiple TRIP Ids per LS
An LS MUST use the same TRIP ID with all internal peers.
Question: what's the significance of TRIP ID between external peers. Can we have a different TRIP ID with different external peers?

JR: In the interest of KISS, since we can't think of a reason to do it, just keep as single ID (consensus)

ITAD boundaries
follows BGP model. Two possibilities:

Allows integrating TRIP-Lite with TRIP. No changes to protocol seems to be required. Seems straightforward - would like to allow it.

JR: Work has been going on for a while. Only minor stuff remains. Finish off for next meeting (similar to CPL).

TRIP for Gateways (TRIP-LITE)
Jonathan Rosenberg

Got mixed feedback in Adelaide, want to convince everybody it's a good idea.

Gateway Management
Problem: need a way to manage routing of calls to heterogenous gatewasy within service provider
Depends on liveness

Can TRIP be used ?
TRIP provides routing exchange inter-domain
Very similar problem

Scope of information restricted due to scale
Scale issues different intra-domain

Thus, need a profile of TRIP

Not a new protocol
Profile of TRIP

SB: It really shouldn't be called anything saying TRIP (marketing confusion). Profiles are a way to say that the original protocol was to complicated. Call it something else

Jon Peterson: Are you sure you want to disallow aggregation? What if I want to build a complex intra-domain network with routes propagated and aggregated among LS's within the domain?

JR: Well, then you are really entering TRIP territory. On the other hand not clear how that would work if you had a single ITAD number. Need to think a little more about it.

Sinnreich: Helps avoid provisioning.

Benefits of TRIP-GW
Information readily exported to normal TRIP interdomain
Allows rapid detection of gateway failures and rerouting
Supports heterogenous gateway farms

Huitema: Defining internal BGP for telephony and that's not a good idea. BGP is lousy for that. Really want to have some kind of special purpose. Doesn't seem like the right tool for the job

JR: Has benefits beyond provisioning.

HS: Not clear this is a good fit. SLP would seem a much better fit. Service discovery is what you want

JR: Disagree - SLP is a pull mechanism. Want a push mecanism.

HS: No. can do service advertisement (at a small scale)

JR: Not convince SLP the right tool, e.g. keepalives

HS: Disagree. May be that a service push protocol is needed, but really not clear that TRIP is the right choice.

Sinnreich: Need to differ between architecturally correct solutions versus short term deployable mechanisms that may not be perfect, but are usable.

WG proposal

JR: Not consensus obviously. Think about the intra-domain routing problem. Two questions

1. Is this problem something we want to address.
2. What are the requirements?

Rohan: Go ahead and use TRIP
Orit: Really a problem.
Hussein: Really two problems. Gateway registration, internal routing, external routing
Jon Peterson: May want to have multi-criteria routing
Radhika Roy: May not want to use TRIP.

JR: Problem can be split into two:

JR: Consensus to adopt this problem as a working group item (not using TRIP, but looking at problem)? YES.

Transit Networks
Dave Walker, SS8

TRIP distributes routes based on E.164 numbers

Sometimes need to route based on carrier however.
Transit network selection indicates (ordered sequence of) preferred carriers

National identification plans

Why should this matter to IPTEL? In the near future, have to allow users access to both IP and PSTN based carriers. Could try to route to gateway nearest destination, then local PSTN call, but want to provide "best" route into the specified network.

TRIP based solutions:

Proposal 1 - New address family route on TN reagardless of dialed number (excl CAC)
new database key value (currently POTS, RoutedNumber)

issue: call signaling may be sup-optimal

Proposal 2 - new attribute type
TN is an optional attribute of E.164 ReachableRoute

can use existing TRIP DBs with addition of new key

issue: complexity

What's next
chose best proposal
ensure all national plans satisfied
clarify intra- & inter-domain behavioral differences

meet requirements of section 5.12 for new attribute specification
describe use of TN is SIP-URLs

Hussein: Three questions:

JR: This seems a clearcut case of a new attribute (your second proposal).

Jon Peterson: Would be nice if you could like at the TRIP-GW problem.

Dave: Draft just intended to introduce problem and get discussion going.

Henning: Country code poor selection as many providers exist in multiple countries. Think about roaming.

Dave: Many scary scenarios. E.g. if going to Europe and carrier is US, then may end up routing calls back to US. Can talk about all this stuff in a future draft.

We agreed that the second proposal is better. However, the proposal requires more work, mainly in two areas:

H.323 URL
Orit Levin


H.323-URL use
A pointer to H.323 "service"

H.225.0 "Alias" Definition
H.323 URL part of H.225.0 Alias

H.323v4 to be decided in November.

H.323-URL Syntax
Have a definition proposed and would like to solicit comments
URL can only have a user-part and a host-part.
H.323 URL resolution not based on DNS resolution solely (obviously).

H.323 specific issues

Rohan: Any parameters proposed ?

H.323-URL will be included in H.323v4
H.323v4 discussion/decision due by the end of August 2000
H.323-URL will be maintained and developed as a part of H.323 Annex O "Internet Technologies Complementary to H.323"
Additional parameters are for consideration

Registration of the URL scheme
According to BCP-35 (RFC 2717)
Two alternatives for registration of the "scheme name"

Would like to get some guidance on which way to go here.

HS: What's the practical implication on having an ITU tree ? Answer: don't know

HS: Talk to Patrik Faltstrom for guidance

HS: User-name or host-name missing distinction was unclear. Problem is that <SIP: foo> will mean something different than <H323:foo>. SIP will refer to host foo, where as H.323 will refer to user foo. Of course clear within each scheme, but somewhat confusing.

OL: Well, the scheme-name makes it clear what it means.

Lennox: Conventional to write URL-schemes in lower-case (h323 rather than H.323).

Lennox: H.323 has slew of alias addresses. Scheme wouldn't allow all of these to be represented in the URL, e.g. "call this E.164 number".

OL: Discussed, but couldn't reach consensus.

Lennox: Add text explaining this in draft.

Lennox: How do you use it ? Send it to the GK which then goes through the whole 323 enchilada. Should describe that a little in the draft.

OL: Annex O describes this.

Huitema: IETF or ITU tree question: Should go for the IETF tree. RFC publish will guaranteee IETF review. URL not used only within H.323. Could very well be used in SIP e.g. to place a call to an H.323 gateway.

Huitema: Can enter any kind of URL ?

OL: Yes. So can easily map between SIP and H.323 URLs. (Not sure I captured this discussion correctly)

OL: prefer IETF tree as well. would like IETF review as well. Will contact Patrik and ask for his input.

OL: registration process is urgent

JR: take what you have, resubmit with lower case, inform IESG that you would like published as Proposed Standard (not Informational), they will look a working group/people to review it.

Service Routing
Out of time. Will post to the list.


CLP: A Language for User Control of Internet Telephony Services
TRIP for Gateways
TRIP: Recent Changes and Open Issues
TRIP Transit Network Support