IP Telephony (iptel) Charter

2.7.6 IP Telephony (iptel)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 28-Nov-01

Chair(s):

J Rosenberg <jdrosen@dynamicsoft.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:iptel@lists.bell-labs.com
To Subscribe: iptel-request@lists.bell-labs.com
Archive: http://www.bell-labs.com/mailing-lists/iptel

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.

Deliverables:

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.
Jan 02		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.

Internet-Drafts:

Request For Comments:

RFC	Status	Title

RFC2824		Call Processing Language Framework and Requirements
RFC2871		A Framework for a Gateway Location Protocol

Current Meeting Report

Minutes of the IPTEL WG meeting
IETF 52
December 2001
Salt Lake City, UT

Minutes taken by: Mary Barnes
Minutes prepared by: Jonathan Rosenberg

The IP Telephony (iptel) working group met for a single one-hour session at IETF 52.

Agenda Bashing
--------------

First up was agenda bashing. The proposed agenda was:

Agenda Bash [Rosenberg] 2m
CPL/TRIP Updates [Rosenberg] 5m
TRIP MIB [Walker] 10m

Gateway Registration
Scenarios: Internet2 [Schulzrinne] 5m
Scenarios: Carrier [Peterson] 5m

Requirements [Rosenberg] 20m

Attributes [Bangalore] 10m

The agenda was agreed to.

CPL and TRIP Status (Rosenberg)
-------------------------------

Jonathan presented the status of CPL. -05 has been issued, finally resolving the year-plus-long dispute with calsch on the level of compliance to rfc2445. Finally, the agreement was to be fully compliant. Performance and security issues were resolvable by doing off-line expansion of recurrence rules. Other changes include the addition of a language-switch and minor fixes. A new WGLC was issued, ending 12/21/01. People were requested to send comments to the list asap.

TRIP -09 approved as an RFC 9/13/01. Its getting close to top of editors queue, maybe 3-4 weeks.

TRIP MIB Open Issues (Walker)
-----------------------------

Lots of comments on -00 (draft-ietf-iptel-trip-mib-00.txt). Most related to SNMP types of things. There were a few open issues. The main one was that one can't easily differentiate TRIBs (Adj-TRIB-IN, Ext-TRIB, Adj-TRIB-Out) in the MIB.
Proposed solutions:
extrapolation, separate tables, bitfield (set).

* Extrapolation - this demands a lot of network manager
* Separate tables - TRIBs can appear in multiple tables
* Bitfield - seems preferable - appears as an extension of existing mechanism which is a boolean

During the discussion, using a pointer was suggested. The response was that the editors understanding was that pointers don't work well with SNMP. Consensus: bit field is agreed solution (no objections).

Other open issues:

o TripPeerRemotePort (added to peer index table) - issue is configured versus learned - multiple servers can share the same IP address. Had been proposed to add a new field RemoteField, however, this has issues with port. Proposed solution: new object (tripPeerLearned) to indicate which is configured vs learned dynamically in protocol.

o Use of TimeInterval (SNMPv2-TC, hundredths of sec) for timers - MIB uses Integer32 seconds. Proposal to use text rather than integer for this field. Proposed solution: seconds used by protocol, marginally easier to configure.

o Oversights:
* Add tripRouteTypeTable to config table (similar to tripPeerRouteTypeTable)
* Add timestamp to route table, will also timestamp last change of peer state.

Conclusion: Will post above on mailing list and new draft will be available soon.

Gateway Registration
---------------------

Precursor: Jonathan highlighted the issue of previous WGs that have had multiple proposals for which there were lots of opinions. This ends up being time consuming as WG often has to backtrack. A plea for being open-minded and focus on progress. The approach we will take is to first be sure we all are solving the same problem, since its not clear we are. So, there will be presentations on scenarios that the gateway registration is solving.

Scenarios: Internet2 (Schulzrinne)
++++++++++++++++++++++++++++++++++

Intradomain Gateway Discovery Requirements

Organizational assumptions:
Not a typical carrier setup
* Possibly "mutual aid"
* Loosely affiliated, with different administrators
o Different university campuses
o Different branches of enterprise

Example Diagram
* Magic in the middle to manage 2 networks

Jonathan asked whether the scenario was gateways as columbia, for example, propagating their information to other university campuses so that those gateways can be used as a communal resource? Henning replied that this is yes, although it could be through an intermediary, he is not proposing a mechanism in this slide.

Jonathan commented that it seemed like this was more like the old wide area service discovery work that was done back when, and whilst its an interesting problem [and indeed, part of Jonathan's PhD dissertation], its not really the problem of this charter item, which is an element in front of a farm of gateways managing the resources of those gateways.

Henning continued with his presentation:

Dynamic configuration
* New gateways or gateway capacity changes
* For university

Policy changes
* New area codes
* Time of day, etc.

Coordination
* May have loose central administrator
* Avoid manual updates and configuration
* Reflect changes rapidly (minutes)

Status updates
* Want to have reasonably accurate picture
* But occasional failure+retry acceptable
* Charging not an issue

Additional considerations
* Multicast may be available
* Gateways are not competitors

Discussion: Is this what people had in mind for Gateway Registration Protocol? Henning said that this may be a slightly different problem, thus perhaps a different protocol may be applicable. Jonathan replied that this doesn't seem to be intra-domain - it appears to be inter-domain. Columbia owns the policy. From a carrier's perspective, the "Gateways are not competitors isn't applicable" and points to this being a different problem. Thus, the requirements introduced by this scenario don't seem to apply.

Henning replied that the requirements are looser, but that doesn't mean the same protocol wouldn't apply.

Cullen Jennings asked whether this would be delivering availability information. Henning responded yes. Update frequency is a protocol parameter that depends on the size of the network. A question was made as to whether, in the model, you expect capacity updates to be sent to all proxies out there? If you expand connectivity, you don't want this data to go to all servers. Not scaleable. Henning replied that you have the scalability problem regardless. This solution (SLP) might do better as it assumes multicast is available.

Another question was about the loosely maintained central admin point - you need much more clear boundaries. Henning replied that it doesn't matter where the information resides; it matters who controls the information. Separate administration from policy control. The gateway is the one with the ultimate decision.

Jonathan said that if you want the gateway to register with lots of proxies, then you need multicast. But, for a single service provider, this is NOT a problem. Henning said that you can pick longer intervals if there are lots of updates. It's more of a protocol tuning issue as to how many messages you can tolerate. Unless protocol has a built in restriction on message frequency. Only really difference is per message overhead (eg. TCP connection setup). Not an issue. Jonathan said that if you're concerned with lots of elements, then certainly multicast is desireable. For a smaller amount of elements, TCP is fine. Henning said that his proposal supports any mechanism. Jonathan said that TRIP doesn't support UDP. Thus, if you need lots of updates, then you are adding an additional requirement. You've got to limit scenarios and limit scope of solution.

Jonathan said that he doesn't think this is the problem that needs to be solved. This doesn't match the charter, although it is an interesting problem.

Then, he posed the question to Group: Is this a scenario that needs to be taken into consideration? Dave Oran replied that this is an interesting problem in the discovery domain and not in route optimization. Finding gateways is not a problem - among a set of known gateways, which is the right one to use. This is an example of a service discovery problem.

Henning replied that there are some attributes independent of protocol choice.

Conclusion: Agreement to hear the next scenario and then continue discussion.

Scenarios: Carrier (Peterson)
+++++++++++++++++++++++++++++

Jon Peterson put up a diagram of his Carrier architecture proposal that was posted to IPTEL WG mailing list.

A type of architecture that he believes will exist (versus one he believes is being deployed)

* Attributes:
1. Has a proxy server
2. Two types of resources - media gateway controllers and standalone (dumb) gateways

* 2 points:
1. Large gateways that are dumb that have physical resources pointing to elements in PSTN.
2. Gateways that terminate to VoIP.

Trunk groups are an important concept here, and represent the finest degree of granularity for policy decisions. Trunk groups can span physical gateways (typical carrier setup for reliability).

Comments on the model:

Brian Rosen: Mostly he likes. It used to be that this was the picture that everyone had in mind that were big carrier types. Are MGs fading away? Always was the argument that you didn't want to put so much into Gateways, thus the separation. But, Moore's law makes this less meaningful. So, perhaps the trend is to combine. Jon replied that you still need signaling gateways to be separate, since you only have a single point code.

Dave Oran said that he thinks that the MGC decomposition is orthogonal. When we talking about IPTEL GWs - MGC is the gateway. Why does this decomposition impact the discussion? Dave also pointed out that an element that's missing from the diagram - show prefixes and trunk groups but don't show carriers. Don't show TGs spanning multiple MGCs. Is that precluded?

Jon replied that his next slide deals with Dave's first point on why the decomposition has an impact. As for the second point, in SS7, a signaling switch is limited to a single point code. Dave said that everyone's gotten around that. There may be a case where TGs can't span GWs, but this shouldn't be the model. This is a low level point that might lead people to the wrong conclusion.

Back to Jon's presentation. Why does the decomposition impact this? It has to do with attributes availability. An MGC advertises its GWs availability, but smart GWs availability known directly.

o Route availability
* Are all MGC routes for '+'? Why express preference?
* Also other address families
o Trunk group availability
* Trunks associated with physical interfaces
* CSI states (blocked locally/remotely, idle, etc.)
* Availability of routes predicted on trunk groups, but often not on a single GW

Jon said he really believes that trunk group availability vs. Gateway availability is the true problem to solve.

Jonathan asked whether the group believes that this is the problem that is being solved?

Discussion:

Dave Oran believes this is the problem. Does have some concerns with the attributes and hierarchy. Jon said he's just trying to describe what needs to be done. Dave Oran responded that we need to work through this. He believes that this is the model - need to be able to find routes to resources (described as a PSTN resource).

Jonathan added one caveat: believes that this is the problem we're solving, but don't get consumed with large carrier model. We need to worry about smaller gateways as well, were there are no trunk groups, where the gateway itself, or routes, are the things to which attributes are associated. However, we need to derive requirements from this general problem.

Jonathan also pointed out that we're not solving SIP to H.323 problem.

Took a hum vote: Is this the problem?
* Yes? Majority hum
* No? No hums!

Further discussion:

Jon said that he believes this should always be about TGs - believes should treat PRI as a trunk. Cullen asked whether there would ever be more than one carrier on a single trunk? Jon said that there are a number of carriers for virtually every trunk. Due to EA. Dave Oran responded that this has nothing to do with it, as the EA concept user experience doesn't necessarily relate. Take it to the list.

Jonathan stopped discussion at this point. Time had run out, and we were not able to cover the last two agenda items:
* Requirements (Rosenberg)
* Attributes (Bangalore)

Conclusion/Actions:
* Agreement to use Jon Peterson's model as the basis for the problem to be solved.
* Take further discussion of Jon's proposal to the list

Slides

Agenda
Gateway Attributes
TRIP MIB Open Issues
Intradomain Gateway Discovery Requirements
Attributes for GW registration