Last Modifield: 05/30/2002
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.
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.
|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|
|MAR 02||Gateway to Server Route Exchange document submitted to IESG for consideration as proposed standard.|
|RFC2824||I||Call Processing Language Framework and Requirements|
|RFC2871||I||A Framework for a Gateway Location Protocol|
|RFC3219||PS||Telephony Routing over IP (TRIP)|
IPTEL WG - Minutes - IETF 55 IPTEL meeting minutes from the 55th IETF Tuesday, November 19, 2002 1700-1800 Salon I Chairs: J. Rosenberg <email@example.com> C. Jennings <firstname.lastname@example.org> ---- Agenda ---- - Status - TGREP issues - 2806 bis issues - Trunk Group issues - CPC/OLI issues (ran out of time and did not cover this) ---- Administrative Stuff ---- Cullen Jennings has joined Jonathan Rosenberg as a co-chair of the WG. There is a new mailing list, email@example.com. You can subscribe via email or at http://www.ietf.org/mailman/listinfo/iptel. People have not been automatically migrated as we could not get the list of subscribers on the old list. The IESG has asked the working group to take on tel URI. We are likely to update the charter and schedule with more URI related items. ---- Status of current work items ---- TRIP MIB: Expert review has been conducted which produced a revised version of the draft. There have been more comments since the revision on the list. We expect that one more reversion of this draft will likely have it ready for IESG. Working group last call was already completed once. TGREP: A new version of this draft has just been submitted. It is in need of expert review. It solves an important problem of preregistering a block of DNs for a gateway. It also provides resource availability information from a single gateway to devices making routing decision about which gateway to use. New work: The IESG has given the working group the mandate to take on telephony related URL items. This could include: 2806bis, draft-yu-tel-url, draft-ietf-iptel-trunk-group, draft-peterson-tel-cpc, draft-brandner-enum-uri. Also discussing draft-levin-iptel-h323-url-scheme (more on this later). When we have reached group consensus on what will be taken on and which document will adopted, the chairs will update the charter. ---- TGREP Presentation by Dhaval Shah ----- TGREP has been changed to be an auxiliary protocol instead of a subset of TRIP. Country codes have been added to the CIC. Open Issue #1 - Thresholding Schemes. Leave them out of the draft or put in more detail? This is an detail implementation issue of a device that will effect how the TGREP protocol performs. There was some discussion of if this should be in a BCP but Jonathan pointed out that we don't have enough field experience to have any hope of knowing what the best practice is. After some discussion people seemed OK with not describing normative thresholding schemes in the draft. Open Issue #2 - Is 128 bytes enough for the trunk group label. Jon Peterson though that 30 bytes would likely be enough so 128 should be fine. No other views expressed. Open Issue #3 - Should carrier codes be ASCII or binary? A few people felt that ASCII would do fine. There were no objections to ASCII. Jon Peterson had done a review and offered to send his comments to the list, most have already been incorporated into the current draft. Chairs put in plea for comments on this draft so we do not have to assign reviewers. This draft seems close to being ready to go to the IESG. ---- 2806bis (tel URI) presentation by Henning Schulzrinne ----- This has undergone significant changes and is considerably narrowed in scope. URI comparisons should be case insensitive but implementation should use lower case letters. The BNF was cleaned up to remove order dependencies but a preferred ordering is specified. This draft is close to WGLC. The intent of the tel URI is to be an abstract address. It is not instructions on how to dial such that you reach a specific location. Open Issue #1 - Context. Is a context needed for a number and if so how is this represented. The classic example is a 800 service number. Ways to represent a context include a DNS domain, a E.164 style prefix, or a list of prefixes. Jon Peterson pointed out there are US 800 numbers that are scoped to bell operating companies, LATAs, countries, etc. Henning Schulzrinne said that he doesn't think it is realistic to generalize URIs to accommodate this. Jon has been uncomfortable with the idea of context and added that the PSTN doesn't have this. For example, a phone number found piece of paper has no context and may not work if you were to arbitrarily use it. Henning explained some of the difficulties in using prefixes to express ranges of numbers. Lawrence Conroy expressed that DNS is likely the "least bad" choice for how to do context but explained there could still be confusion on if the context ibm.com meant IBM's internal network or was an external context. Jonathan pointed out that this context problem exits in other places such as an HTTP URL. The practical solution has been, if you find a URL, you can only use it in a context in which it is valid. Henning wanted us to consider the more radical step of not allowing local scope URI. (the U part of the URI.) Always having context would eliminate much of the silliness that happens today. He brought up the example of the problems that happened with the tv: URL. Jonathan leant more towards not providing context in the tel URI and just making sure that you did not send URLs out of scope. This would still allow local scope. Dave Oran pointed out that "speed dial" configuration was the same problem. Dave thought we should punt on trying to figure out if a given thing was in the scope or not. Flemming Andreasen thought it would be useful to have a context. Henning commented that in many cases, the tel URI was more like a URN than a URI. This is especially true for service numbers. Jonathan argued this was not a tel URI specific problem and felt like a much bigger issue for someone else to solve. Jonathan said this draft is devoid of semantics on URI processing or any information on what you should do with one of these things. The meeting moved on to other topics but clearly this context topic needs more discussion on the list. Open Issue #2 - Global numbers - are they global? Global numbers are of the E.164 form. Some of them like +1-800-356-9733 look like global numbers but are not. It may not be possible to call them form many countries of states. [There has been significant discussion on the list since the meeting on this topic] Next steps: There was some short discussion on what it takes to get this to draft standard. One of the items needed with be an interoperability matrix. Henning would appreciate people contacting him if they have implemented tel URL. Lawrence Conroy talked about how all of this changes the expect behavior of clients from the behavior in RFC 2806. These changes are not backwards compatible and will break existing systems. At least one system that is used for internal use only would be broken by this. It is not a requirement that this bis draft has to be backwards compatible but the working group need to decide what we want to do. Another issue that came up about going to draft standard is the question of the status of the normative references. Allison Mankin confirmed that all normative references need to be draft standards before this can go to draft standard. There is only one normative reference, RFC 2396. There is a 2396bis in progress, and Jonathan will check as to whether this is going to draft standard or not. ---- Trunk Group presentation by Vijay Gurbani ---- The trunk group work has been motivated by the need to be able to indicate which of several different PSTN connections a single gateway should use for a given call. Open Issue #1 - Should the trunk group indicator be carried in a SIP or tel URI? Right now it is in a tel URI. Open Issue #2 - Should a trunk group label be in a local or global namespace? Discussion centered around the proposed double equal sign syntax in the draft. Henning thought this did not look like a good idea but Rohan Mahy pointed out the list of legal choices was small. Please, anyone, propose something better on the list. Open Issues #3 - How to represent both the originating and terminating trunk group in the same SIP message? The current proposal puts the terminating in the request URI and the originating in the Contact. Jonathan brought up that there are no semantics for the tel URI but here we are bringing up semantics for SIP. If the tel URI is defined well enough, then there will be no need to do anything special for SIP. Dave Oran's comment on this was that Jonathan is underestimating the perversity of the implementers. There were no objections to the idea of SIP having a trunk group indicator in a Contact header field value or a request URI. Open Issue #4 - Proxies should be able to change or add a destination trunk group to a request. ---- Items Moving Forward ---- Do we want to have a draft to extend the tel URI to include trunk groups? Richard Shockey requested the ENUM URI work be moved to the IPTEL group. We need to decide how/if we want to proceed with this. The draft-zhao-iptel-gwloc-slp draft is solving a somewhat different problem than the TGREP and TRIP works so it will continue to proceed as an individual work. Jon Peterson commended that he submitted the CPC draft for discussion only and he does not necessarily think it should be a charter item. Orit Levin has been working hard an getting a draft documenting the H323 URL scheme. This was in the RFC editors queue but pulled back. Rohan brought up that this draft is entangled with the Annex O work for H.323. After some discussion it came up that one of the issues on this draft is if the WG or IETF can make any changes given that this is already in competed ITU specifications. Jonathan is going to discuss this with the ADs and Orit before deciding how we can move forward on this. A more detailed version of the minutes was send to the list and is at http: //www1.ietf.org/mail-archive/working-g roups/iptel/current/msg00060.html Thank you Andrew for recording the minutes.