2.8.5 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:

       http://www.softarmor.com/iptel/ -- Additional IPTEL Page
NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-20

Chair(s):
Jonathan Rosenberg <jdrosen@dynamicsoft.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: www.ietf.org/mail-archive/working-groups/iptel/current/maillist.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.

Deliverables:

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

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
Internet-Drafts:
  • - draft-ietf-iptel-cpl-08.txt
  • - draft-ietf-iptel-trip-mib-09.txt
  • - draft-ietf-iptel-tgrep-02.txt
  • - draft-ietf-iptel-trunk-group-00.txt
  • - draft-ietf-iptel-rfc2806bis-02.txt
  • Request For Comments:
    RFCStatusTitle
    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

    IETF 58 IPTEL Meeting Minutes
    Reported by Tom Taylor <taylor@nortelnetworks.com>

    The IPTEL Working Group met on Wednesday morning, 12 Novemeber.  The
    meeting was chaired by Cullen Jennings <fluffy@cisco.com> and Jonathan
    Rosenberg <jdrosen@dynamicsoft.com>.

    The agenda was accepted as proposed:

    1. 10 minute status update
    2.  user=phone discussion.

    Status

    Cullen Jennings presented.  

    CPL (draft-ietf-iptel-cpl-08.txt)

    The draft was reworked to remove dependencies on caller prefs.  The
    XML basis was changed to Schema from DTD. WG Last Call is complete.
    Will send to IESG for reinsertion into the RFC Editor's queue.

    RFC2806bis (draft-ietf-iptel-rfc2806bis-02.txt)

    The draft has completed WG Last Call.  It will be submitted to the
    IESG unless the discussion regarding the user=phone parameter leads to
    changes.

    TGREP (draft-ietf-iptel-tgrep-02.txt)

    The draft is ready for final NITS review, WG Last Call.

    TRIP MIB (draft-ietf-iptel-trip-mib-09.txt)

    After lots of discussion back and forth between the editors and the
    MIB doctor, another revision has come out.  The document is now ready
    for sending to the IESG.

    Other stuff:

    Calling Party's Category tel: URI parameter (draft-mahy-iptel-cpc-00.txt)
    tel: URI parameters (draft-yu-tel-url-08.txt)
    trunk group (draft-ietf-iptel-trunk-group-00.txt)

    Need expressions of interest to take these forward.

    Tom Taylor mentioned that the Yu and Mahy drafts were of particular
    interest to those working on interworking of SIP to the PSTN.
    Jonathan responded that the question is whether the proposed
    functionality is needed in the SIP network.  Flemming Andreasen
    <fandreas@cisco.com> and Richard Stastny <Richard.Stastny@oefeg.at>
    indicated their interest in those drafts.  Another speaker indicated
    his interest in the trunk group draft.

    Cullen said he would contact James Yu to see if he was still
    interested in carrying his draft forward.  Jon Peterson indicated that
    James was still interested, but had some concern on the content of
    2806bis.

    Jonathan emphasized that he was only prepared to add these drafts as
    WG items if he sees interest on the list. He asked for list comments
    and/or document revisions by mid-December, or we would not continue.

    A milestones update slide was presented.  The chairs are looking to
    close the WG by March.  There was no comment on the proposed
    milestones.


    user=phone discussion



    Rohan Mahy <rohan@cisco.com> presented the issue based on slides
    worked out between him and Brian Rosen <Brian.Rosen@marconi.com>.
    These slides reflected the results of discussion on the SIPPING list,
    also captured by Rohan's draft
    (draft-mahy-sipping-user-equals-phone-00.txt).  

    There is just one major point of disagreement.

    The points of agreement:

    1. Don't mess with the user part of a SIP URI that isn't yours.
    2.  Some SIP domains have user parts which are numbers.  Sometimes these can conflict with phone numbers.
    3. Some people need user=phone.

    Disagreement: how to distinguish "dial strings" from phone numbers.

    The subsequent discussion was lively and wide ranging.  The following
    notes capture a number of the points, but not all of them.

    Tom Taylor noted that number transformations occur at various points
    along the call path, not just at the first hop.

    Brian Rosen pointed out that user=phone is broken no matter what, and
    his proposed fix is one way to solve the problem.

    Two speakers expressed the view that interoperability is more likely
    to be achieved if the approach taken was to use separate phone
    contexts for telephone numbers and dial strings.

    Francois Audet <audet@nortelnetworks.com> asked why the proposed
    dialstring syntax used E and F rather than * and #.  It appears that
    2806bis doesn't allow * and #.

    Henning Schulzrinne <hgs@cs.columbia.edu> expressed a preference for
    explicit semantics hence, in this case, allowing the user=dialstring
    parameter.

    Someone remarked that if you don't want to put phone-context in, then
    you shouldn't set user=phone.

    Jonathan Rosenberg wondered how developer could distinguish a
    telephone number from a dial string if the IETF cannot.  Context
    defines a name space.  That should be adequate.

    Dean Willis <dean.willis@softarmor.com> made the point that "9,411" is
    actually a request for a gateway to provide a specific service --
    outpulsing according to a specific cadence.  This is a specific
    instance of the general class of service requests.

    Brian Rosen picked up Dean's point and elaborated on it.  He has a
    further need: to provide guidance to a proxy server that serves
    multiple domains.

    Henning said this provided further support for user=dialstring; it is
    a parameter pointing to a specific operation.

    Richard Stastny added his support for user=dialstring because phones
    cannot dial E.164 numbers.

    Dick Knight <dick.rr.knight@bt.com> pointed out that this was
    effectively pushing the distinction problem back to the UA.

    Another person pointed out we already have two mechanisms to transmit
    the requirement to pause: KPML and 2833.  We don't need another.

    Tom Taylor repeated his point that the network may need to do number
    translation beyond the first hop -- hence it is desirable to have a
    general mechanism to indicate that the user part is in a
    context-specific form.

    Richard Stastny agreed that digit manipulation is definitely needed at
    the first hop, but shouldn't be needed thereafter.

    Brian Rosen explained why KPML wouldn't work.  It is easier to get
    user=dialstring to work.

    Francois Audet expressed his view that allowing user=dialstring not a
    big deal.  Pause is a different discussion.

    At this point the chairs used a series of hums to determine the
    general opinion of the meeting.

    1.   agreed: the presence of the user=phone parameter implies that the user part conforms to the specification of the tel: URI.
    2. agreed: user=dialstring accepted as a new SIP URI parameter. (Pause is a separate discussion.)  Further to this last point there were some strong objections to NOT allowing  user=dialstring, little in the way of strong objection to user=dialstring.  The chairs decared consensus on that point.

    Brian Rosen volunteered to write a draft defining user=dialstring.
    This will be an individual contribution to SIPPING, to be considered
    at the request of IPTEL.

    There was a split view on whether getting pauses to the gateway is a
    problem.  The discussion will be taken to the list.

    Slides

    Agenda
    Phone numbers and dial strings