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 <firstname.lastname@example.org>
Transport Area Director(s):
Scott Bradner <email@example.com>
Allison Mankin <firstname.lastname@example.org>
Transport Area Advisor:
Scott Bradner <email@example.com>
To Subscribe: firstname.lastname@example.org
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 email@example.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.
Submit call processing syntax document to IESG for consideration as a Proposed Standard.
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
IPTEL, IETF 48
Minutes taken by: Flemming Andreasen
Minutes Edited by: Jonathan Rosenberg
IPTEL met for a single 2.5 hour session during IETF 48 in Pittsburgh.
- Agenda bashing
- CPL open issues, Jonathan Lennox
- TRIP ope issues, Hussein Salama
- TRIP-GW update, Jonathan Rosenberg
- transit networks in TRIP, Dave Walker
- H.323 URL, Orit Levin
- Service Routing, Jonathan Rosenberg
CPL Open Issues
Jonathan started by describing the changes in revision 2 of the CPL
specification. THe main changes were:
- Time handling reworked: matches iCal
- H.323 mappings
- XML and MIME types
- New string switches: language , display
- Enhancements of Node
Time handling was the biggest change:
- moved from crontab format to iCal (RFC 2445 - Proposed Standard)
- makes it easy to create CPL srcitps automatically from calendars
- rich syntax
- complicated to evaluate (interoperatbility problems reported, some bugs in spec)
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:
- tzid (time zone identifier: server-local or from a to-be-defined IANA registry)
- tzuel (time zone URL: reference to a RFC 2445 VTIMEZONE)
<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
- Mappings defined for H.323 address types.
- H.323 has addresses both in Q.931 part and H.323 UUIE part. Not clear which one takes precedence, but server should use same rules for CPL as it uses for routing.
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
- H.323 alias address have ~8 different possible formats
- Define mappings for each of these into CPL address subfields (done)
- also define new alias-type address subfield for H.323 servers
- Based on H.323v4, to be publishd in November; introduces H.323 URL scheme. Is this a problem for last call ?
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.
- Is this really ncessary, given remove-location location ="*"
changes to proxy and reidirect nodes
added output redirection to proxy nodes
- Weakened server support for scripts that do not conform to the DTD from SHOULD to MAY
- More examples
- DTD updated
Todo and proposed enhancements
- Add q parameter to location nodes (needed for priority order)
- Draft asserts H.323 has no equivalents
- Clarify how extensions should work: XML namespaces.
- Complaints about default timeout value for proxy being dependent on whether noanswer output is present or not. Jonathan R. initially raised this concern but has relented, as it makes the most sense. So, we will specify that the default timeout value is dependent on the presence of noanswer.
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 prsented the recent changes and Open Issues for TRIP.
Next Hop Server Format
- Comment from Adelaide: to represent the next hop server by domain name or IP address in DNS format
- Open issue: Transport type: UDP/TCP (proxy.ietf.org.transport-tcp).. do what SIP does.
- Open issue: Representation of IPv6 addresses in TRIP.
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.
- Currently: route types supported and Send Receive Capability
- IANA considerations
- Reserved capability code 0
- Capability codecs 32768 to 65535 for vendor-specific capabilities
- Open Issue: making "route types supported" mandaty E.g. may only be interested in SIP or H.323 routes.
- Open Issue: adding "Capability Mismatch" error code
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.
Reserved type codes 224 to ?
Added two new apl. protocols RAS and H.323 Annex G.
Letters other than 10 digits used in Europe.
Had to deviate from IANA's standard set of address families.
Define two address families
- POTS numbers: private, local, national, and internation (0-9)
- routing numbers: mainly for European LNP (0-9, A-F)
May want to deifne other address families in the future, e.g. URL.
Reserved ITAD numbers 0 and 65535
ITAD numbers 64512 to 65534 are for private use
Proposal: Use domain names instead of ITAD numbers. Issues:
- No need for IANA registration
- ITAD topology restrictions
- Effect on AdvertisementPath and RouterPath attributes (domain name would imply long attribute names)
SB: Running into trouble with 16-bit fields for AS. Change to something bigger for ITAD.
MED and Tie Breaking Rules
- MED usage consistent. Higher MED is preferable
- Changed tie breaking rules to favor internal routes over external routes
Protection of peer sessions using IPSec
- Transparent mode security association
- Either AH or ESP
Protect route itself over multiple hops:
- Sign critical attributes of the route
- Include list of signatures in Authentication attribute. If intermedia changes, must remove signature and resign itself
- Open Issue: What signature mechanism to use ?
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)
follows BGP model. Two possibilities:
- On the link between two LSs
- On the LS itself. Splits the LS box into two (or more) virtual LSs. Permits route summarizatioin of TRIP-Lite routes.
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)
Got mixed feedback in Adelaide, want to convince everybody it's a good idea.
Problem: need a way to manage routing of calls to heterogenous gatewasy within service provider
Depends on liveness
- Depends on availability (capacity, etc.)
- Depends on matching capabilities of call
- Depends on cost of termination
Can TRIP be used ?
TRIP provides routing exchange inter-domain
Very similar problem
- prefix propagation
- attributes and capabilites
Scope of information restricted due to scale
Scale issues different intra-domain
- Can add additional information needed to support GW management
- Can update information more frequently
Thus, need a profile of TRIP
Not a new protocol
Profile of TRIP
- Used particular components
- No aggregation or redistribution - that's normal TRIP
- Additional attributes for this configuration
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.
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:
- Propagation of information to proxy from a gateway
- Propagation of information between proxies
JR: Consensus to adopt this problem as a working group item (not using TRIP, but looking at problem)? YES.
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
- Q.931 setup, ISUP IAM
National identification plans
- ANSI ISUP: 4 digits (0-9, B,C) administered by NANPA
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)
- POTS, RN still advertised separately (useful if TN not selected)
issue: call signaling may be sup-optimal
- correct route may require both E.164...
Proposal 2 - new attribute type
TN is an optional attribute of E.164 ReachableRoute
- reachign all E.164 (ie. "*") equivalent to new address family
can use existing TRIP DBs with addition of new key
- affects E.164 aggregation
chose best proposal
ensure all national plans satisfied
clarify intra- & inter-domain behavioral differences
- e.g. does carrier prefer internal gw to TN over own external
meet requirements of section 5.12 for new attribute specification
describe use of TN is SIP-URLs
Hussein: Three questions:
- Why always have country-code as part of identifier. Answer: May look into that
- Using attributes proposal: problem is you get two routes and TRIP would drop one of them. Answer: draft explains this. route selection would have to change
- First proposal with separate AF. We would need to correlate them somehow.
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:
- specify how aggregation will work
- specify how "searching the RIB" will be affected. Previously the two search keys were address and application protocol. Now the CIC attribute is a third search key. Significant change.
- publish H.323-URL definition as an Informational RFC
- Register H.323-URL with IANA
A pointer to H.323 "service"
- To be carried in H.323 messages
- To be used in web-pages
H.225.0 "Alias" Definition
H.323 URL part of H.225.0 Alias
H.323v4 to be decided in November.
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).
- The H.323 URL host portion is Case Insensitive
- The host numbers are defined to be used without square brackets
H.323 specific issues
- GK identifier as a part of "host" portion (using UNICODE, so will probably have to restrict to ASCII use)
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"
- IETF tree
- An alternate (ITU ?) tree
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.
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