2.8.9 IP Telephony (iptel)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional IPTEL Page

Last Modified: 2004-11-02


Jonathan Rosenberg <jdrosen@cisco.com>
Cullen Jennings <fluffy@cisco.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Jon Peterson <jon.peterson@neustar.biz>

Mailing Lists:

General Discussion: iptel@ietf.org
To Subscribe: iptel-request@ietf.org
In Body: put subscribe in subject
Archive: http://www.ietf.org/mail-archive/web/iptel/index.html

Description of Working Group:

The focus of the IP Telephony (iptel) group is on the problems related
to naming and routing for Voice over IP (VoIP) protocols.
Naming is accomplished through the use of the tel URI, which specifies
a URI for telephone numbers. The tel URI was originally defined in RFC
2806, which was developed outside of any IETF working group. The iptel
working group is responsible for updating the specification based on
extensive experience with the tel URI. It is chartered to develop any
extensions to the tel URI, such as support for number portability
indicators and trunk groups.

Routing protocols for VoIP allow intermediaries, such as SIP proxies
and H.323 gatekeepers, to make call routing decisions based on
reachability information learned from peer elements. The iptel group
has already defined a protocol, Telephony Routing over IP (TRIP), RFC
3219, 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.

TRIP and the gateway registration protocol are orthogonal to the
DNS-based mechanisms specified in ENUM and RFC 3264. Those mechanisms
are used to translate a URI, representing a name, to an address. If
that address is a phone number in the telephone network, trip and tgrep
can be used to assist in determining the right route (through various
gateways) to that number.

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 specification for gateway to server route

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

3. A standards track update to the tel URI.

4. Standards track extensions to the tel URI for PSTN interoperability,
such as number portability and trunk group identification.

Goals and Milestones:

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.
Done  Submit gateway location protocol document to IESG for consideration as an RFC.
Done  TRIP MIB Document submitted to IESG for consideration as proposed standard
Jun 03  Gateway to Server Route Exchange document submitted to IESG for consideration as proposed standard.
Jul 03  Tel URI revisions submitted to IESG
Sep 03  Number portability extensions submitted to IESG for consideration as proposed standard
Nov 03  Consider closing


  • draft-ietf-iptel-tgrep-04.txt
  • draft-ietf-iptel-trunk-group-02.txt
  • draft-ietf-iptel-rfc2806bis-09.txt
  • draft-ietf-iptel-tel-np-02.txt

    Request For Comments:

    RFC2824 I Call Processing Language Framework and Requirements
    RFC2871 I A Framework for a Gateway Location Protocol
    RFC3219 PS Telephony Routing over IP (TRIP)
    RFC3872 Standard Management Information Base for Telephony Routing over IP (TRIP)
    RFC3880 Standard CPL: A Language for User Control of Internet Telephony Services

    Current Meeting Report


    TUESDAY, November 9, 2004, 1300-1400

    CHAIRS: Jonathan Rosenberg <jdrosen@cisco.com>
    Cullen Jennings <fluffy@cisco.com>
    Note-taker - Spencer Dawkins <spencer@mcsr-labs.org>

    Status Update: Since last meeting we have published TRIP MIB and CPL. 2806bis was published shortly after the meeting.

    Enum dip indicator: Richard Stastny presented draft-stastny-iptel-tel-enumdi. This would add a flag that indicated that the ENUM dip had been done and did not need to be repeated. General consensus in room was to accept this work. Some discussion about if there should be a way to indicate that dips had been done to different roots. Eventually decided that there are no current documents specifying ENUM for multiple roots and we would not do this.

    draft-ietf-iptel-tel-np-02.txt Revision is coming and it will be WGLC and hopefully finished. Volunteers agreed to review. Some interested in implementing this.

    draft-ietf-iptel-trunk-group-02.txt Volunteers agreed to review. Need to WGLC. Some interested in implementing this.

    Dial string draft: will go forward as individual submission

    Calling party category draft: This has expired with very little response to comments. There is substantial work left to finish this. One or two people in room thought they might implement it. Not clear what the key uses of it are. Will discuss on list if we want to move forward with this (as a WG item) or not. It could always be done as individual.

    More detailed notes follow:

    * TRIP MIB, CPL published as RFCs since last meeting of IPTel
    * rfc2096bis in RFC editor queue
    20 min Enum Indicator Richard Stastny -
    * Also heads-uped in ENUM
    * Add "enumdi" to E.164 tel URI saying "we've already done an ENUM lookup, so you don't have to try again when you're resolving the URI"
    * "MUST NOT attempt e164.arpa resolution" requirement also discussed in ENUM
    * Who can add "enumdi?" - if you would do ENUM, you can add it, and an endpoint can add it to the original URI before anyone tries to resolve it
    * Cullen points out that this is not a mandatory parameter, so network elements that don't understand it will still attempt the lookup
    * <>This is good. Why limit it to e164.arpa? There will be other lightweight mechanisms, too.
    * <><>2806bis should probably also be a SHOULD - how consistent do we need to be?Makes sense, but do we need to say this in the current draft?
    * <><>If we allow this for multiple routes, we need to say what routes have been queried. Should we add a translation counter to help people realize a URI has been changed? How does transitive trust work? And please don't change semantics in a future rev - do it now, or don't do it.
    * Allow other roots in the first version, too - won't this slow the document down on the approval process?
    * If you know who did the lookup, you can decide whether to trust them based on that knowledge.
    * Leave it like is, or extend it (loop counter or something else)? Not a significant difference in sense of the room. We're trying to shut the working group down, so the authors will be guided by whatever the chairs ask for.
    * We don't actually have a spec that says you can legitimately query against another domain. Jonathan doesn't get it... no harm in redoing the lookup ("dip").
    * Punt this question to the ENUM working group chair :-) - service providers would like to do something like this. Would like to continue as a working group document, would like to rev quickly and WGLC quickly.
    * Ignoring this is like ignoring NATs - don't put our heads in the sand. We'll block for six months to a year if we add alternative roots.
    * Accept as WG item with no changes - humm? Sense of room is "yes". [still needs to be confirmed on the list, right?]
    30 min Plan for concluding work - Chairs Et.Al.

    * Number portability draft revision is coming and addresses comments to date.
    * Volunteer reviewers were selected for NP and trunk group drafts.
    * Lite interest in implementing NP extensions and trunk group drafts. Will be immediately WGLCed. Reviewers, please report back during that timeframe. Dial string draft
    * will go forward as individual submission
    Calling party category draft
    * has expired, no responses to comments received
    * some concerns raised (trust boundaries, asserted identity) - not near done with this one.
    * We discussed making this a WG item many moons ago, and decided not to do it for pretty much the same reasons being raised now.
    * This work will take some time to get right. If the working group takes it on, we have to expect to come to consensus before we can close.
    * This work is useful, but maybe doesn't matter whether it's a WG item or not.
    * Who would implement? maybe one or two in the room
    * Not sure who needs this - what problem is being solved? duplicate parameters, endpoint identification - what? Maybe emergency services and coin phones, or something like that. Check with development groups and discuss this on the list in a couple of weeks after end of IETF. ENUM Dip?
    * We think we decided to do this at the beginning of the meeting.


    Enum dip indicator