News on Standards Developments for Fax, Unified Messaging and Related Technologies for IP and other networks
| In This Issue . . . |
| Introduction from the Publisher |
| Introducing MEGACO (Media Gateway Control) Working Group |
| Links to Fax Glossary |
The amount of standards activities have continued to increase in the areas related to facsimile, unified messaging and telephony that have traditionally been covered by Human Communications Digest. This has been a major challenge for the editorial staff of this newsletter and we have been juggling items and been bound by space constraints for our last several issues. In particular, the explosion of Internet based communications technologies such as Internet Fax, Internet Printing and the Voice Profile for Internet Mail have resulted in an expanded scope for HCD.
At Human Communications Digest, we want to continue to bring our readers the premier coverage for these standards areas as we have during the past seven years. Therefore, as of this issue, we are initiating a supplement to HCD which will be published on our web site.
The articles to be posted will be written in the same reader friendly style that is familiar to HCD readers and will undergo the same editorial scrutiny. The actual content to be posted will vary depending upon how busy the period has been and which items seem best suited for posting in the web format.
Our regular issue will continue to be available in hardcopy and Adobe Acrobat forms on a subscription basis (see www.humancomm.com/abouthcd.htm for details). The supplement will be posted in HTML form and our plan at this time is to make it freely available on our web site. We plan to notify our HCD subscribers and the other business contacts of Human Communications about the posting of the supplement when applicable via HC News and Notes, which is sent via outbound email. (To subscribe to the HC News and Notes mailing list, send an email message to ellenr@humancomm.com with the word subscribe in the message body). We will also include a reference to "HCD on the Web" within the main body of the newsletter. Welcome! If you have any comments, please send them to us at jrafferty@humancomm.com
#####
The Megaco working group on Media Gateway control began earlier this year. There is related work taking place in the ITU within Study Group 16 and recently, the two groups have decided to work together to produce a common set of standards for the protocols that are used to control media gateways. The concept of Media gateways is an outgrowth of the substantial movement toward moving some portions of the current circuit switched public telephone network infrastructure to use IP and other packet based technology. As this evolution occurs, there will be a need for media gateways which can take circuit switched telephone calls involving various media such as voice and fax, and then translate them for conveyance over an alternate network. In turn, it is envisioned that there will be a need for media gateway controllers which will be used to detect the type of incoming telephone call and then direct the call to the appropriate type of media gateway. The primary focus of the Megaco working group is to develop the requirements and the protocol to be used between Media Gateway controllers and Media Gateways.
Chair Tom Taylor convened the meeting of the Megaco working group on July 15, 1999 in Oslo, Norway. Over the course of the meeting, an explanation emerged on how the IETF and ITU plan to work together on this standards effort.
At the May meeting of Study Group 16, the Internet Society (on behalf of IETF) was represented by Transport Area Director Scott Bradner among others. Question 14 of Study Group 16 determined a document called H.GCP at that meeting. Determination is the first step of the ITU approval process and in this case, approval of a final recommendation is targeted for February, 2000. H.GCP is a protocol specification for interactions between Media Gateways and Media Gateway Controllers. Informally, an agreement was reached between the question and the IETF Megaco WG that both groups will be working on the H.GCP document and that the ultimate goal is to produce joint text that will be published both as an ITU-T recommendation and as a standards track RFC. This is the first time that an attempt has been made to produce a joint text between IETF and the ITU. For example, the Internet fax cooperation has relied upon the use of mutual references within the IETF and ITU documents. . A pointer to the draft that was discussed at the IETF WG meeting (essentially the draft H.GCP) is :
ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/megacoHGCP5.pdf.
The specification for the requirements of this protocol is under review in the IETF, with the draft name being <draft-ietf-megaco-reqs-05.txt>. This document still has a lot of missing pieces, which is consistent with the status of the rest of the work. The gameplan is to get the documents into shape through lots of discussion and some interim meetings involving both the ITU and the IETF.
Some upcoming key events are:
1. Posting of an updated draft - the editors have been at work and have posted an updated draft that reflects results from the IETF Megaco meeting.
2. There is a rapporteur's meeting in early August in Berlin. The intent is to do more editing on the current draft as it exists at that point.
3. There will be another SG16 meeting in October, from which a white contribution version of H.GCP (now called H.248) will be generated.
4. It is likely that there will be further document changes prior to the ITU decision meeting in Feb 2000.
There were at least 200 people at the IETF meeting and the Megaco list has been an active one, so there is definitely lots of industry interest in this effort. The intent (at least as expressed at the IETF) is that the resulting H.248 framework will be designed to work with media gateways that may be built using either the H.323 or SIP/SDP infrastructures.
A summary of other topics from the meeting follows. The chair is: Tom-PT Taylor <taylor@nortelnetworks.com>
Transport Protocol Review
Tom Taylor began the review of this topic by noting that a design group had been meeting during the week to do work on various open issues related to the Megaco protocol. He noted that the existing "audit" concept had been split into two commands, since two different facilities were involved: 1) status discovery and 2) capability discovery. In a related item, he noted that the new Media descriptions and media capability syntax may have some overlap with the MMUSIC and CONNEG charters.
There are two competing protocol stacks from the ITU and IETF which are designed to handle either point to point or multi-point communications over IP networks, H.323 and SIP/SDP. Taylor noted that to be fair to H.323 and SIP, both need to be supported in the Megaco work.
As a result, the current thinking is:
There has also been an issue on whether the basic encoding for the protocol should be text oriented or use a tag-length-value (ASN.1) oriented approach. Taylor characterized this as more of a political than a technical issue.
There was a brief review of the functional requirements for Capabilities within the Megaco protocol:
There is currently no obvious solution for feature differences between SDP and H.245. Some possible ways forward are:
The group has a desire for a template concept that would help support capabilities negotiations, signals and events in the following manner. Basically, the desire is that if a certain set of parameters are used frequently, they could be represented by a more compact form and be retrieved as needed (note: this is similar to the rationale that Conneg is using to developing a hash representation for groups of features). The exact approach to be used to support a template concept has not yet been specified.
There are some concepts on capabilities that emerged from the work of the design team. Elements of this approach would include:
1. Use flexible tags that can be registered with IANA
2. one of the tags could be an EmbeddedSDP tag, which could be used to embed SDP content into the Megaco protocol
3. This could enable a native protocol to be coherent, but still provide enable the media gateway to use either SDP or H.245 in their implementation.
Regarding the matter of whether to use a Binary (ASN.1) or text based (ABNF) syntax for defining the Megaco/H.248 protocol, Taylor indicated that there was no logical way to pick between the two. As a result, the "coin flip" method was used to select the use of ABNF syntax; therefore, the ABNF syntax will be edited back into the draft. (Note: At the Berlin ITU meeting in August, after further discussion, it was agreed that ASN.1 could be used for those implementors who want to support a binary encoding. Therefore, a normative annex will be added to H.248 which expresses the protocol in an ASN.1 form for those implementors who want to use a binary encoding. This decision was very controversial on the Megaco discussion list, but it looks like the compromise to support both encodings will hold.)
In some examples of the syntax, an implementation could use some of the following commands: (Status - current commands; Capabilities - what is the full list of capabilities?). It was noted that an Events Descriptor is a "request ID" followed by a list of events.
The syntax design team suggests getting rid of termination class in favor of packages. Instead, a package would be used to describe things and the packages would be pre-defined ( for use with events, signals, etc.) . The response to an "audit" would provide the list of packages supported. It was also noted that there is a need to show simultaneous capabililities for communication among multiple parties. After the syntax review, it was concluded that the text based syntax needs a bit more refinement before it is put into the next draft.
Security
Tom Taylor led the discussion on security. One voice from the audience suggested that the decision would clearly be to use the emerging IETF security approach known as IPSEC (the updated version is RFC 2401). However, Area Director Scott Bradner countered that the ADs want the WG to seriously consider IPSEC, but this is not a path to be followed blindly.
Some issues related to IPSEC in the context of the Megaco work were discussed. One problem is that IPSEC is the recommended way to provide security to the IP protocol and will then protect higher layers, but IPSEC is layered in between the IP and UDP portions of UDP/IP protocols. Therefore, if the embedded implementation of the protocol stack does not yet support IPSEC, it cannot be added unless protocol implementor's have direct access to the stack. It was noted that for many of the embedded OSes that would be used to build Media Gateways, there are not yet compatible IPSEC implementations available.
As a result, a partial solution is contained in the current text, such that some of the IPSEC code for the authentication header is placed in front of the Megaco header. The chair noted that he did not agree with this solution. Bradner suggested that there may be value in keeping the IPSEC semantics, while using explicit headers in the protocol. Under this scheme, the UDP header is not protected.
The conclusion for the discussion was as follows: 1) If IPSEC is available, use it , or, 2) When IPSEC is not available, use the subset of IPSEC headers. It was suggested from the floor that MGCs SHALL support IPSEC. This would place the more complex stack in the controller, rather than requiring it also to be present in the lighter weight Media Gateways.
In other items, it was noted that there is also a need to do extensions to SDP on new parameters for support of transport layers such as Frame Relay and ATM. This would be done via IANA (Internet Assigned Numbers Authority) extensions. There are also provisions for permitting "X-…" extensions for private extensions.
Taylor suggests that the syntax should be revised to enable after the fact extensions to be added via extension procedures. In other words, the item to be extended needs to be described in a way such that IANA can deal with the extension in its role as a registration authority. One concept is to possibly have separate RFCs which are prepared to define an SDP descriptor and an H.245 descriptor. This would address putting this information in a form which can be passed between the MGC and the MG.
Taylor suggested that Study Group 16 will not like the suggestion of transferring H.245 information directly between the MGC and MG. Instead, there will be a need for a way to wrap or map this information (e.g. for example, SG16 may want to wrap H.245 in ASN.1 for transport over the wire).
Transport Layers
It was suggested that several different lower layers are likely to be used for different applications of Megaco. Some alternatives were briefly presented:
TUDP and MDTP are protocols that are work in progress elsewhere in the IETF.
Another approach was characterized as the use of Megaco + UDP + timers. This would be a layered approach, evidently specific to Megaco.
There was some discussion on requirements for Megaco and on whether the various proposed methods were a good fit.
For example, it is felt that there is a need to be able to back out a transaction and to have congestion control. It was noted that methods to detect congestion and relief of congestion conditions are not available for TUDP.
The functional characteristics of the Megaco protocol will evidently involve the exchange of lots of back and forth streams, sent first in one direction and then in the other. The group held some of the usual debate on the relative merits of UDP type protocols vs. TCP/IP for Megaco.
It was noted that a protocol can be designed so that you can do congestion control without changing the lower layer protocol. In this instance, the protocol stack will basically just use or adapt the current TCP congestion management algorithms.
There was an issue on whether there should there be a way to pass the TOS (diffserve element) down to a different layer. There is an interest by implementors in being able to do this. It was noted that the relevant Diffserve RFC needs to be finished in order for it to be referenced.
It was suggested that there will a different set of stacks for the Media Gateway Controller (the left side) and the Media Gateway (the right side). So, under this theory, the left side would use lower layers developed by other groups (TCP/IP, TDP, MDTP) and the right side would use " Megaco + UDP and timers", also called Application Layer Framing. Essentially, the Left side engineering approach would be to use existing layers, but adapt them for use in Megaco. There will be a need for timers at the application and transport levels in either case (left or right side). In addition, Quality of Service aspects will need to be addressed (i.e. QOS permits some packets to be assigned higher priorities than others).
In a comment from the room, one of the TCP developers said that in retrospect, congestion control does not belong in the transport layer itself, but in a related "shim" layer, not buried in the protocol. The concept here would be to push the congestion management down to lower layers, but also to get a tighter coupling between the transport and the application layers.
Tom Taylor held some Straw Polls to get a sense of the room on this transport issue.
The initial set of choices were:
a. TCP Mandatory only
b. Application Layer Framing Mandatory only
c. TCP and ALF both mandatory
d. MGC has both TCP and ALF mandatory; MG must support either ALF or TCP or both
There was some support for both c and d, over a and b. The rough consensus was for d. This tentative agreement will be also sent to the Megaco list for confirmation
In some further brief discussion, it was argued that it is not practical to have TCP in Media Gateways.
Packages
The primary means of extending the Megaco protocol to handle additional functionality is via packages. Packages contain information, events and signal descriptions related to a specific class of functionality. There was some discussion on packages. From the protocol-01 draft, there are examples of packages which include Generic, dtmf, handset, script , and so on. There are also other packages that are being reviewed which include the IP phone package.
It was mentioned that a related API is being developed. However, the encoding of the package data into actual packets is yet to be resolved. It was noted that signals and events are driven by a function call like syntax. The IP phone document < draft-ietf-megaco-ipphone-00.txt> and another document use this syntax. For example, in the case of an IP phone, there may be many IP phones which interact with a single Media Gateway Controller via a series of signals and events.
The following schedule was noted for the IP Phone RFC:
The IP Phone work has been taking place primarily within the TIA 41.3.4 committee, which is providing inputs into the IETF.
Taylor stated that packages are one of the items that will be subject to extension via the submission of new codepoints to IANA. James Rafferty and Scott Bradner suggested the that WG needs to be very careful about the matter of references in their cooperation with the ITU. In response, Taylor noted that the current plan is that extracts from the IANA reference material prepared by the IETF will be bolted into the ITU recommendation as Annexes. The IANA docs may be informational or have another status within IETF. Taylor further noted that there will be a need for editors on individual packages.
#####
Home | What's New?
| About HC | Publications and
Services | Order Forms
Publications | Consulting Services
| Fax Class Info | Fax Glossary
| Press Releases