Current Meeting Report
Jabber Logs

2.8.6 IP Telephony (iptel)

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
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/30/2002

J. Rosenberg <>
Transport Area Director(s):
Scott Bradner <>
A. Mankin <>
Transport Area Advisor:
Scott Bradner <>
Mailing Lists:
General Discussion:
To Subscribe:
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:
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
MAR 02  Gateway to Server Route Exchange document submitted to IESG for consideration as proposed standard.
  • - draft-ietf-iptel-cpl-06.txt
  • - draft-ietf-iptel-trip-mib-03.txt
  • - draft-ietf-iptel-trip-gw-00.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)

    Current Meeting Report

    IPTEL WG - Minutes - IETF 55
    IPTEL meeting minutes from the 55th IETF
    Tuesday, November 19, 2002
    1700-1800 Salon I
     J. Rosenberg <>
     C. Jennings <>
    ---- Agenda ----
     - Status
     - TGREP issues
     - 2806 bis issues
     - Trunk Group issues
     - CPC/OLI issues (ran out of time and did not cover this)
    ---- Administrative Stuff ----
    Cullen Jennings has joined Jonathan Rosenberg as a co-chair of the WG.  
    There is a new mailing list, You can subscribe via email or 
    at People have not been 
    automatically migrated as we could not get the list of subscribers on the 
    old list.
    The IESG has asked the working group to take on tel URI. We are likely to 
    update the charter and schedule with more URI related items.
    ---- Status of current work items ----
    Expert review has been conducted which produced a revised version of the 
    draft. There have been more comments since the revision on the list. We 
    expect that one more reversion of this draft will likely have it ready for 
    IESG. Working group last call was already completed once.
    A new version of this draft has just been submitted. It is in need of 
    expert review. It solves an important problem of preregistering a block of 
    DNs for a gateway. It also provides resource availability 
    information from a single gateway to devices making routing decision about 
    which gateway to use.
    New work:
    The IESG has given the working group the mandate to take on telephony 
    related URL items. This could include: 2806bis, 
    draft-yu-tel-url, draft-ietf-iptel-trunk-group, 
    draft-peterson-tel-cpc, draft-brandner-enum-uri. Also discussing 
    draft-levin-iptel-h323-url-scheme (more on this later). When we have 
    reached group consensus on what will be taken on and which document will 
    adopted, the chairs will update the charter.
    ---- TGREP Presentation by Dhaval Shah -----
    TGREP has been changed to be an auxiliary protocol instead of a subset of 
    TRIP. Country codes have been added to the CIC.
    Open Issue #1 - Thresholding Schemes. Leave them out of the draft or put in 
    more detail? This is an detail implementation issue of a device that will 
    effect how the TGREP protocol performs. There was some discussion of if 
    this should be in a BCP but Jonathan pointed out that we don't have 
    enough field experience to have any hope of knowing what the best 
    practice is. After some discussion people seemed OK with not 
    describing normative thresholding schemes in the draft.
    Open Issue #2 - Is 128 bytes enough for the trunk group label. Jon 
    Peterson though that 30 bytes would likely be enough so 128 should be 
    fine. No other views expressed.
    Open Issue #3 - Should carrier codes be ASCII or binary? A few people felt 
    that ASCII would do fine. There were no objections to ASCII.
    Jon Peterson had done a review and offered to send his comments to the 
    list, most have already been incorporated into the current draft.
    Chairs put in plea for comments on this draft so we do not have to assign 
    reviewers. This draft seems close to being ready to go to the IESG.
    ---- 2806bis (tel URI) presentation by Henning Schulzrinne -----
    This has undergone significant changes and is considerably narrowed in 
    scope. URI comparisons should be case insensitive but 
    implementation should use lower case letters. The BNF was cleaned up to 
    remove order dependencies but a preferred ordering is specified. This 
    draft is close to WGLC. The intent of the tel URI is to be an abstract 
    address. It is not instructions on how to dial such that you reach a 
    specific location.
    Open Issue #1 - Context. Is a context needed for a number and if so how is 
    this represented. The classic example is a 800 service number. Ways to 
    represent a context include a DNS domain, a E.164 style prefix, or a list of 
    Jon Peterson pointed out there are US 800 numbers that are scoped to bell 
    operating companies, LATAs, countries, etc. Henning Schulzrinne said that he 
    doesn't think it is realistic to generalize URIs to accommodate this.  Jon 
    has been uncomfortable with the idea of context and added that the PSTN 
    doesn't have this. For example, a phone number found piece of paper has no 
    context and may not work if you were to arbitrarily use it. Henning 
    explained some of the difficulties in using prefixes to express ranges of 
    numbers.   Lawrence Conroy expressed that DNS is likely the "least bad" 
    choice for how to do context but explained there could still be 
    confusion on if the context meant IBM's internal network or was an 
    external context.
    Jonathan pointed out that this context problem exits in other places such as 
    an HTTP URL. The practical solution has been, if you find a URL, you can 
    only use it in a context in which it is valid. Henning wanted us to 
    consider the more radical step of not allowing local scope URI. (the U part 
    of the URI.) Always having context would eliminate much of the 
    silliness that happens today. He brought up the example of the problems 
    that happened with the tv: URL. Jonathan leant more towards not 
    providing context in the tel URI and just making sure that you did not send 
    URLs out of scope.  This would still allow local scope.  Dave Oran 
    pointed out that "speed dial" configuration was the same problem. Dave 
    thought we should punt on trying to figure out if a given thing was in the 
    scope or not. Flemming Andreasen thought it would be useful to have a 
    context. Henning commented that in many cases, the tel URI was more like a 
    URN than a URI. This is especially true for service numbers.
    Jonathan argued this was not a tel URI specific problem and felt like a 
    much bigger issue for someone else to solve. Jonathan said this draft is 
    devoid of semantics on URI processing or any information on what you 
    should do with one of these things. The meeting moved on to other topics but 
    clearly this context topic needs more discussion on the list.
    Open Issue #2 - Global numbers - are they global?
    Global numbers are of the E.164 form. Some of them like 
    +1-800-356-9733 look like global numbers but are not. It may not be 
    possible to call them form many countries of states. [There has been 
    significant discussion on the list since the meeting on this topic]
    Next steps:
    There was some short discussion on what it takes to get this to draft 
    standard. One of the items needed with be an interoperability matrix.  
    Henning would appreciate people contacting him if they have 
    implemented tel URL.
    Lawrence Conroy talked about how all of this changes the expect 
    behavior of clients from the behavior in RFC 2806. These changes are not 
    backwards compatible and will break existing systems. At least one system 
    that is used for internal use only would be broken by this. It is not a 
    requirement that this bis draft has to be backwards compatible but  the 
    working group need to decide what we want to do.
    Another issue that came up about going to draft standard is the 
    question of the status of the normative references. Allison Mankin 
    confirmed that all normative references need to be draft standards before 
    this can go to draft standard. There is only one normative reference, RFC 
    2396. There is a 2396bis in progress, and Jonathan will check as to 
    whether this is going to draft standard or not.
    ---- Trunk Group presentation by Vijay Gurbani ----
    The trunk group work has been motivated by the need to be able to 
    indicate which of several different PSTN connections a single gateway 
    should use for a given call.
    Open Issue #1 - Should the trunk group indicator be carried in a SIP or tel 
    URI? Right now it is in a tel URI.
    Open Issue #2 - Should a trunk group label be in a local or global 
    Discussion centered around the proposed double equal sign syntax in the 
    draft. Henning thought this did not look like a good idea but Rohan Mahy 
    pointed out the list of legal choices was small. Please, anyone, propose 
    something better on the list.
    Open Issues #3 - How to represent both the originating and 
    terminating trunk group in the same SIP message? The current proposal puts 
    the terminating in the request URI and the originating in the Contact.
    Jonathan brought up that there are no semantics for the tel URI but here we 
    are bringing up semantics for SIP. If the tel URI is defined well 
    enough, then there will be no need to do anything special for SIP. Dave 
    Oran's comment on this was that Jonathan is underestimating the 
    perversity of the implementers. There were no objections to the idea of SIP 
    having a trunk group indicator in a Contact header field value or a 
    request URI.
    Open Issue #4 - Proxies should be able to change or add a 
    destination trunk group to a request.
    ---- Items Moving Forward ----
    Do we want to have a draft to extend the tel URI to include trunk 
    Richard Shockey requested the ENUM URI work be moved to the IPTEL group.  We 
    need to decide how/if we want to proceed with this.
    The draft-zhao-iptel-gwloc-slp draft is solving a somewhat different 
    problem than the TGREP and TRIP works so it will continue to proceed as an 
    individual work.
    Jon Peterson commended that he submitted the CPC draft for discussion only 
    and he does not necessarily think it should be a charter item.
    Orit Levin has been working hard an getting a draft documenting the H323 URL 
    scheme. This was in the RFC editors queue but pulled back. Rohan brought up 
    that this draft is entangled with the Annex O work for H.323. After some 
    discussion it came up that one of the issues on this draft is if the WG or 
    IETF can make any changes given that this is already in competed ITU 
    specifications. Jonathan is going to discuss this with the ADs and Orit 
    before deciding how we can move forward on this.
    A more detailed version of the minutes was send to the list and is at 
    roups/iptel/current/msg00060.html Thank you Andrew for recording the 


    TGREP Update
    RFC 2806bis: tel URI
    Trunk Group Open Issues