NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 31-Jul-98
Chair(s):
Jonathan Rosenberg <jdrosen@bell-labs.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@ee.lbl.gov>
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:
May 98 |
|
Issue first Internet-Draft on service framework |
Jul 98 |
|
Submit framework ID to IESG for publication as an RFC. |
Aug 98 |
|
Issue first Internet-Draft on Call Processing Syntax |
Oct 98 |
|
Submit Call processing syntax to IESG for consideration as a Proposed Standard. |
Dec 98 |
|
Achieve consensus on basics of gateway attribute distribution protocol |
Jan 99 |
|
Submit Gateway Attribute Distribution protocol to IESG for consideration as a RFC (info, exp, stds track TBD) |
Internet-Drafts:
No Request For Comments
Minutes of the iptel wg session at the 42nd IETF, Chicago, IL
8/24/98
Notes By: Francois Menard, Wilhelm Wimmreuter
Reported By: Jonathan Rosenberg
The session opened with a presentation of the agenda, which was basically three main
items:
1. Open issues in gwloc framework document
2. Call processing syntax update
3. Fixing charter and milestones update
There was no objection to the agenda, so the meeting progressed to a discussion of the
gwloc framework open issues.
The first item was to try and define some common terms so as to establish a consistent
framework for discussion. Several terms were defined, including gateway, user agent,
location server, and provider. The question was raised about the relationship between
a gateway provider, ISP, ITSP, etc. The chair indicated that in our architecture, a
provider provides gateways, and that this provider need not be an IP service provider.
As a result, a provider "domain" in our context is not the same as an ISP domain or
Autonomous System (AS) in routing terminology. The domain represents the logical
collection of gateways and location servers owned by a single entity.
The next issue for discussion was the scope of the gateway discovery being worked on.
The chair noted that it was important to decide which case we are working on, since the
requirements for each are different, and therefore the protocol might be different in each
case. It was noted that even though we engineer the protocol to solve one of the cases, if
it happens to be a good fit for one of the other ones, great, but we shouldn't engineer for
it. Four cases were presented:
1. Intra domain. In this case, the gateways are all owned by the same administrator.
The gateway location protocol allows a number of location servers, also owned by
this provider, to automatically learn about the gateways within the domain. In this
case, issues such as policy and aggregation, and requirements for security,
scalability, and robustness, are different than in the other cases.
2. Inter-domain (1): In this case, the gateway location protocol is being used to
exchange information on gateways between providers. Providers have location
servers, which know about gateways within their own domains. How they know is
the scope of an intra-domain gateway location protocol (which is something
different). This information is exchanged with peers, and may be aggregated and
further passed on to other peers. The "peering relationships" between provider
location servers are not the same as the BGP peering relationships used to exchange
routing. The protocol is independent of normal routing exchanges. In order to
exchange information, a pre-established peering relationship must be built ahead of
time between providers.
3. Inter-domain (2): In this case, the gateway location protocol is also used
to exchange information between providers. However, it would be based on some
kind of multicast model, so that a gateway provider would just advertise widely
its gateway characteristics. Any location server or client could receive these
advertisements and learn about remote gateways and gateway attributes in remote
domains. This differs from inter-domain (1) in that no pre-established relationships
need to exist. It becomes an "open market" allowing anyone to advertise and
anyone to receive.
4. Inter-domain (3): This case is like (1), except that the gateway reachability
information and attributes are pushed into existing inter-domain routing protocols.
This has been suggested on the list. The chair raised concerns about this overloading
existing routing infrastructures, and also requiring significant upgrades for carriers,
even those who don't offer IP telephony gateway service. There was consensus that
we shouldn't be doing this, although it had been pointed out that the E.164 space
would fit into IPv6, so it might be appropriate to do this in that context.
Then he proceeded by explaining the importance of defining in the draft how to deal
with inter-domain vs intra-domain, since they have different requirements.
There was then some discussion on these various scenarios. An important question was
raised about the distinction between discovery and qualification. Since the domains we
are talking about are virtual, a provider may learn about another gateway, but the
gateway may not actually be reachable by the provider, or the gateway may be reachable
but by unacceptable QoS. The chair commented that he felt it was not within our scope
or charter to add QoS routing into the protocol. He proposed to leave path qualification"
to external means, and not part of the protocol. It was argued that it needs to be integrated
into the protocol. There was no consensus and it was decided to try and resolve it offline.
It was then suggested that a query could be made every time a gateway was required,
and the gateways could return some kind of bid, allowing the caller to decide among the
bids and choose a gateway. The chair raised concerns about the scalability of a multicast
query for each call setup, and he argued that routing protocols propagate this information
ahead of time to eliminate these kinds of queries.
There was general consensus that we were trying to solve the inter-domain (1) problem.
The chair then went on to further scope the inter-domain (1) problem. The first question
was whether we were trying to solve the single hop or multiple hop problem. In the
single hop case, providers exchange information about their own gateways with each
other. In the multi-hop case, there are intermediate providers which can aggregate and
advertise this aggregate information. In either case, the call terminates on a single
gateway, but the issue is really whether there are intermediate location servers (which
would often be gatekeepers or SIP servers) or not. The chair indicated that the difficulty
with the multi-hop case is that its not clear aggregation is possible, since there are so
many attributes.
Scott Petrack than pointed out that in order to make this determination, we should
consider what attributes might actually be used for a gateway. Scott Bradner indicated,
however, that even in the simple one hop case, a providers location server will need to
aggregate gateway information from its own gateways. As a result, we are effectively
doing the multi-hop case anyway. The chair agreed, and consensus was reached that the
multi-hop, single gateway case would be supported by the protocol. It was agreed,
however, that aggregation was a complex problem.
The next issue was that of multiple gateways. In this scenario, for example, a call
begins from a PC endpoint, hops through several location servers, jumps off the IP
network onto the PSTN through a gateway, to another gateway, back onto the IP
network, through some more location servers, and then back off the IP network to the
PSTN towards a PSTN terminal. This has been mentioned on the list as something we
may want to do. The question is - does it require additional support from the protocol,
and if so, do we want to engineer that support into the protocol?
Jim Udall felt that such a scenario might arise in the connection of islands of mso's. The
chair pointed out, however, that instead of treating the PSTN as the PSTN, and
terminating the application layer protocols on the gateway, one could treat the PSTN
connection as a dial on demand IP link, and thus the problem still effectively looks like
a single gateway case. Scott Bradner also pointed out that one could always use these
intermediate hop-off and hop-back-on connections internally without advertising them,
so that the protocol doesn't need to be aware that its being done. There was general
consensus that we should not try and solve the multiple gateway problem.
The next issue was what the attributes for a gateway might be. The chair presented a
slide with a number of posible attributes, which include phone number reachability,
cost, protocol support, encryption, call features, codecs, administrator, vendor, capacity,
etc. It was pointed out that many of these were static, and that we would need to
handle dynamic attributes too.
Christian Huitema expressed concern that too many attributes will cause a
"multiplication effect" in the aggregated announcements from providers. Therefore, to
be scalable, we must stick to attributes which are hop by hop or which can be aggregated
end to end. It was mentioned that a MIB is being developed for gateways, and that this
would be a valuable starting point for determining which attributes might be propagated.
There was no consensus on which attributes might be included, and it was agreed to
continue discussions offline and on the list.
The next issue was what range of numbers a gateway can be allowed to advertise
reachability to. In other words, gateways can complete calls to certain sets of telephone
numbers, and these need to be advertised. Is there a restriction on what this set is? The
chair indicated that there are reasons why a provider would want to advertise only local
numbers (thats what will be cheapest), or all numbers (a gateway can complete a call to
any number - its in a providers business interest to advertise as broady as possible). The
chair indicated that the decision is really a business one, and that he felt the protocol
should be engineered to support whatever business decision a provider makes. Scott
Bradner agreed, and the consensus was to engineer the protocol to support whatever
phone number range a provider decides to advertise. It was also pointed out that there
was an ion protocol for phone number advertisements in an IP to ATM address
resolution service, and that we should take a look at this to see if its relevant and how
they handled some of these problems.
The next open issue discussed was that of how a user specifies input to the selection
process. The chair presented a model which consists of a front end and a back end. The
back end is the protocol which distributes gateway attributes among service providers.
Based on the information received, service providers can aggregate, filter, and propagate
this information, and also build up their own local databases of gateways. When a user
wants to make a call, it seems there are many ways in which they can access this
database and express preferences. These include:
1. An LDAP or other database query from the client to the location server
2. The Service Location Protocol (SLP) - a location server can act as a DA, and the
clients can run UA's and formulate service queries
3. The location server can create dynamic web pages, and the clients can browse the
web pages,
4. The location servers also act as gatekeepers. When the client sends a call setup
message to the gatekeeper, the gatekeeper consults its gateway database and
forwards the request accordingly
5. The location servers act as SIP servers. A SIP INVITE request from a client can
contain preferences about gateway selection.
It doesn't seem to be mandatory to standardize a single mechanism. Different providers
can use different approaches as they see fit. Thus, the chair proposed that the group
work just on the back end mechanism, and leave the front end mechanisms for later on.
Masataka Ohta asked for the front end mechanisms to be added to the charter right
away. Scott Bradner indicated that first we should at least complete the gateway
location framework document, and then we could consider adding items to the charter.
The next item on the agenda was updating of the milestones. The chair indicated that
the milestones were outdated, for two main reasons: (1) the group changed the order
of doing things, so that we are focusing on the gwloc protocol first, and (2) the timelines
were proposed well before the wg was approved, so they were already out of date by
the time the group began meeting. An additional problem was that a gwloc framework
document was not part of the current charter. It was proposed that it be added. The
following dates were proposed as main milestones:
1. gwloc framework document submitted to IESG: Jan 99
2. gwloc protocol document submitted to IESG: Apr 99
3. call processing syntax framework submitted to IESG: Apr 99
4. call processing syntax submitted to IESG: Sep 99
The area directors agreed that these dates were acceptable, and consensus was achieved
that we would go with these.
The next item on the agenda was a presentation by Jonathan Lennox on the call
processing syntax. He indicated that the plan for the scripts is to live anywhere (end
systems or network servers), be persistent for a transaction, and be independent of the
means by which they are transported. The last meeting had brought some questions
regarding feature interaction issues. Jonathan addressed the interaction issues from
three definitions. In interaction case 1, two features are on at once - for example "call
waiting" and "call forward busy". In the CPL context, services are not defined by
names, but rather on conditions, so this kind of interaction shouldn't be a problem.
Interaction case 2 is when multiple scripts execute on the same server. In general, there
will be some ordering to these, and so they will execute in series as if they were actually
running on separate machines. This leads to the third case, that of multiple scripts on
different servers. Some interactions are signaling protocol issues (for example, the
signaling protocol should probably detect loops to avoid the problem when call
forwarding is executing on both machines), and some are unavoidable (outgoing call
screening on one machine, and transfer on another machine, where the transfer is to a
forbidden site).
Jonathan then presented an idea to use XML as a syntax for creating the call processing
script. The main motivation is that it is safe, easily written by hand or computer, and
easily parseable. Furthermore, since it is good at representing tree like structures, it can
easily represent services which are defined by tree like decision, as is often the case in IN.
There are many open issues remaining, some of which were presented. For instance,
how are timeouts handled? What is the granularity of features specified in the syntax?
Should call queue, for example, be a primitive or constructed from lower level
primitives? Should the syntax be call specific, or apply to other communications
services, such as fax, email, and presence?
As time was running out, there was little time for discussion or questions. There were
a few comments on related work.
With that, the meeting was adjourned.
None received.