NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00
Chair(s):
Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Mailing Lists:
General Discussion:iptel@lists.research.bell-labs.com
To Subscribe: iptel-request@lists.research.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:
Done |
|
Submit gateway location framework document to IESG for consideration as an RFC. |
Jan 00 |
|
Submit call processing syntax framework document to IESG for consideration as an RFC. |
Apr 00 |
|
Submit call processing syntax document to IESG for consideration as a Proposed Standard. |
Apr 00 |
|
Submit gateway location protocol document to IESG for consideration as an RFC. |
Internet-Drafts:
· A Framework for a Gateway Location Protocol
· CPL: A Language for User Control of Internet Telephony Services
No Request For Comments
IETF 47
Adelaide, Australia
Monday, 19.30 - 22.00
Minutes taken by: Joerg Ott
Minutes prepared by: Jonathan Rosenberg
Agenda Bashing
--------------
Agenda:
Agenda Bashing 5mins Rosenberg
Status of docs 5mins Rosenberg
Framework for IIN 15mins Slutsman
TRIP 45mins Rosenberg
TRIP for GWs 15mins Rosenberg
CPL 45mins Rosenberg
Agenda accepted w/o modifications.
Status of documents
-------------------
- CPL Framework
- submitted to the IESG for Informational
- approved & awaiting RFC #
- TRIP Framework
- resubmitted in March
- under consideration now
Framework and Requirements for the Internet Intelligent Networks
----------------------------------------------------------------
- presented by Lev Slutsman
[draft-lslutsman-sip-iin-framework.txt]
Outline
- Generalized IIN architecture
- transparent access from SIP network to traditional IN services
- Internet service creation
- API fo service creation
Transparent access to traditional IN services
- Motivation
- PSTN and VoIP network will coexist for some time
- reuse of h/w (SCP, SN, SMS), software, service logial
- time-to-market for introduction of VoIP services
- proposes to include access to traditional IN together with IP-based service creation (CPL, CGI)
- APIs
Generalized IIN Architecture
Traditional IN Architecture
Arhictecture (cont.)
- based on remote execution logic
- SoftSwitch layer makes SCP believe that it deals with switches
- challenge is to map SIP FSM onto SSP FSM
Internet-based service creation
- The execution of the service logic takes place on the server
Generalize IIN Architecture
- how to invoke service logic (e.g. script)
- use a trigger database
- trigger + ordered list of programs to be executed
- trigger = SIP-call-leg + State
- in addition, information that comes with a message, along with "global" variables are used by service logic
Two approaches proposed:
* The Distributed Service Creation Environment
* The Centralized Service Creation Environment
There were no comments on this work.
TRIP Changes
------------
- Jonathan Rosenberg
Overview
- Authentication Attribute
- Intra-domain Flooding algorithm
- Removal of Marker
- Next hop can be IP address or domain name
- LocalPreference must be used as received
- Minor attribute semantics
Auth Attribute
- list of signatures
- each signature is over a specific attribute
- signature data includes
- ITAD of signer
- TRIP ID of signer
- Auth Algorithm
- Signature
- Signature covers ReachableRoutes and attribute
TRIP Internal Flooding
- purpose: sync the database of all LSs within a domain
- method: link-state based
- topology determination
- contains peering relationships at each LS
- allows LS to determine internal topology
- peering changes flooded to all LSs
- ITAD topology:
- a list with identifiers of an LSs internal peers
- flooded to peers when peering changes
- strictly intra-domain
- link state encapsulated attribute
- Link State Encapsulation
- purpose: detect loops
- applies to three attributes
- contains sequence number and originator
TRIP databases
- Adj-Trib-In
- Adj-Trib-External
- Loc-Trib: one per LS
- Adj-Trib-Out: one per external peer
Flooding of Routes
- if Adj-TRIB-External changes
- status of a route originating at LS changes
Receiving Flooded Routes
- check if its a loop
- looped if originator = me
- received a route with same SN already in DB
- if no loop, check if its newer than route in DB. If so, add.
Route Selection
- run on Adj-TRIB-Ins of peers and Adj-TRIB-External
The point was emphasized about the need for the TRIB-External. Its main purpose is to enable faster convergence. When an internal peer crashes, all other internal peers already have the best external routes, and so they can all switch to this one, rather than waiting for the new best route to be propagated.
Withdrawing routes
- must hold withdrawn routes for some time
Removal of Marker
- original purpose was Auth and Sync in BGP
- we don't need it for Authentication
- using Ipsec
- not actually used for synchronization
- removed it
Next Hop Address formats
- previously, was just IPv4 and IPv6. Want to add domain name.
motivation: DNS support for load balancing can be used, also allows indirection step
Dave Oran asked why we should even bother with IPv4 and IPv6. Rather, just use domain names. After all, this is an application layer protocol, not a layer 3 routing protocol. In any case, you can always allow IPv4 or IPv6 addresses as strings, just like a domain name.
- domain names only?: significant enough issue to take it to the list, but there seemed consensus to do it.
Local preference
- clarification that local preference must always be used, and not recomputed.
Attribute Flags
- some clarifications
Pending Changes
- TRIP port number: 6069
- addition of community attribute
- send/recv/send-recv capability
Community Attribute
- found many uses in BGP4
- probably useful for us
- optional
- may as well include it now
Send/Receive/SendReceive
- useful for an LS to declare it will only
- send routes
- receive routes
- both
- default is both
- if receive only, peer LS must not send
- send-only applications (gateway, next presentation)
- receive only application (monitoring systems)
Dave Oran expressed some concerns about send only and receive only. In particular, an LS which was send only to some peers and receive only to others could cause bizarre topology problems that foul things up. Thus, this capability must apply to the LS, rather than its relationship with peers.
Open Issues:
- the list is getting smaller
- Main issues
- default timer values
- usage of TRIP Ids
- authentication mechanisms
- Hop by hop security
- Confederations
Default Timer Values
- taken from BGP4 timer defaults
- new one: max purge time
Comment: IS-IS uses 90 minutes for this timer; we may want to follow suit. Do we want to change any of the other ones? It was noted that you can always change the value of some of these (like the keepalive timer), and that we were really discussing the default. In that case, it may not matter.
Usage of TRIP IDs
- spec says it can be different for each external peer
- If you do monitoring, you may want to use the same TRIP ID
Authentication mechanisms
- used in auth attribute
- none are currently specified
- probably not a bad idea to have just one
- Proposals?
- None so far. People are encouraged to get back to the list. Brian Rosen volunteered to look into this and come back with suggestions.
Hop-by-Hop Security:
- Ipsec
- However:
- ESP
- transport
- keying
- Help!
- Propose { ESP, Transport, IKE } on the list.
- See what the reactions are.
Confederations
- collection of routes learned from peers all members of the same consortium
- problems using community attribute
- maybe we need a new attribute?
- Do we need or want this?
Dave Oran: no idea where this came from? What to use it for? Also, you will need security for this to be useful. In that case, why not use the use the signer of the attribute as indicator of the conferederation?
- Seems reasonable. discuss on the list
WG Last Call to happen before next IETF
- There are three different types of routes belonging to H.323
- a single value to idenfify a route belonging to H.323 may not be sufficient
- needs to be clarified with H.323 folks
However, there has been consensus in the past that RAS is not something that needs to be addressed by TRIP.
Usage of TRIP for Gateway Route Exportation
-------------------------------------------
- Jonathan Rosenberg, Hussein Salama
Problem
- how do proxies/LS learn about gateways in their domain
- what addresses can they route to
- are they alive or down
- currently done through static configuration
Why not SIP REGISTER?
- semantics are wrong
- timing is bad
- scaling is bad
TRIP is an ideal solution
But TRIP is so hard...
- very small subset of TRIP needed for this
Minor change to TRIP
- wasteful if LS sends UPDATES to g/w
- use recv-only
Dave Oran commented that this mechanism also provides a sanity check on the routes injected by the gateway
- double check that the TRIP-IDs of all routes are identical.
Dean Willis commented that its preferable to configure gatways from a central point rather than learning what the gateway can rech from the g/w. In this case, this mechanism is not needed. The response was that this is not routing; this is central configuration.
- Comments were solicited to determine whether this work was worthwhile to pursue.
CPL: Call Processing Language
-----------------------------
Jonathan Rosenberg, presenting for Jonathan Lennox
revision of CPL with a lot of changes
make it work for H.323 and SIP
- without making it work for the two independently
Changes from the previous version:
New structure: top-level actions
- <call> -> <incoming> + <outgoing>
- timezones
subactions
- similar to subroutines (instead of the previous "goto"s)
new switch: address switch
- string comparison is hard to achieve the right results
- does not work for H.323 at all
- define address-switch tag that is general purpose
- define semantics and map them to the respective protocol fields
new switch: priority-switch
change: string-switch
- removed glob matches
- case insensitive matching with locale independent normalization
change: time-switch
top-level attribute: timezone
- defines sets of timezones in format similar to timeswitch
Dave Oran commented that we don't need another format for timezones. Rather than inventing one, why not reuse the format in the config files for Unix? Conclusions:
- some already well-defined way is definetely a nice-to-have
- further input (e.g. on an XML standard for this purpose) is solicited.
change: added <not-present> output tag
- taken when desired field not in request
Lookup: changes
- added caller preferences integration
- source can now be URL
- added timeouts
New tag: remove-location
- allows for address filtering
Proxy tag: changes
- recurse (yes,no); ordering (parallel; sequential; first-only); timeout
Other tag changes
- response -> reject
- notify -> mail (uses also mailto: syntax)
- mail loses failure output
Other model changes
- initial location list for local outbound requests
- default actions defined
Many open issues:
Open Issues: H.323 bindings
- textual way to represent an H.323 URL
- What H.323 free forms strings should be matched?
- review needed from the H.323 community
Open Issues: language details
- timezone
- ok, we have proposal from today
- many other minor issues
Open Issues: identifiers and XML
- DTDs vs. Schemas
- input solicited
There was no other comments during the discussion. There were generally nods of support throughout, indicating general support for the changes.
None received.