Internet Engineering Task Force Christian Huitema INTERNET DRAFT Telcordia Technologies May 20, 1999 Expires: November 20, 1999 Providing H.245 like capability exchanges with Megaco, using SDP Status of this document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract: This memo is a contribution to the ongoing debate in the Megaco working group on the use of SDP or H.245 to describe Termination Descriptors. One of the stingy point in the debate has been the need, for some gate- ways, to provide H.323 compatible "capability exchanges." It has some- times been asserted that such exchanges would be hard to provide with an SDP syntax. This memo, on the contrary, provides a simple solution to the problem, based on the following ideas: * usage of SDP to describe termination parameters, * usage of the audit procedure to enquire about capabilities, * a syntax in the audit procedure allowing to return several Huitema [Page 1] Internet draft Megaco capacities with SDP 20 May 1999 termination descriptors, corresponding to alternative capability sets, * an algorithm for translating a set of SDP encoded capability sets into an H.245 capability descriptor. 1. Introduction: There is an ongoing debate in the Megaco working group about the choice of a syntax for "termination parameters" and possibly also the "termina- tion capabilities." The tension results from the need to support two types of signalling between distributed media gateways systems composed of controllers (MGC) and gateways (MG), and also between distributed systems and non distributed multi-media systems: * Systems abiding to ITU specifications follow the H.323 series of recommendations, * Systems abiding to IETF specifications follow the Session Invita- tion Protocol (SIP, RFC 2543), * Some systems supports variations of the ISDN User Part (ISUP) sig- nalling procedures (ITU recommendation Q.761, 762, 763 and 764.) The choice is essentially between three alternatives: * Use the syntax specified in SDP (RFC 2327), as used in SIP, * Use the syntax specified in H.245, as used in H.323, * Define a new syntax. Discussions on the working group showed that there was considerable sup- port for SDP, some support for H.245, and a complete unwillingness to define a new syntax: * Supporters of SDP generally point out that it is a simpler solution (5 pages of ABNF), and thus a better fit for small systems such as "residential gateways". They also assert that the text syntax, combined with IANA registration procedures, provides for easy extensions with complete backward and forward compatibility. * Supporters of H.245 point out that this is a more complete solu- tion, with a rich set of features such as capability negotiation. However, there are some very vocal opponents to H.245, which is perceived as too complex (more than 50 pages of ASN.1 specifica- tion) and hard to extend. Extensions are typically performed as syntax extensions, which, combined with the particularities of the Huitema [Page 2] Internet draft Megaco capacities with SDP 20 May 1999 packed encoding rules, generate incompatibilities between succes- sive versions. * While theoretically possible, the definition of a completely new syntax is generally ruled out. A new syntax would require its own registration procedure for future extensions, with the risk of nei- ther being compatible with SIP nor with H.323. This memo explores the possibility of using the extensions procedures that are already defined in the SDP syntax to provide the capability negotiation procedures required for interworking with H.323 systems. In order to set up the problem, we will first repeat the definition of the cabality exchanges in H.323 (in fact, H.245), and the extensions procedures defined in SDP. 1.1. Parameters of the Capability Exchange messages In order to compose a Capability Exchange message, the transmitting ter- minal assigns a number to each individual mode the terminal is capable of operating in. These numbers are the index of the capability in a capabilityTable. For example, G.723.1 audio, G.728 audio, and CIF H.263 video would each be assigned separate numbers. These capability numbers are grouped into AlternativeCapabilitySet structures. Each AlternativeCapabilitySet indicates that the terminal is capable of operating in exactly one mode listed in the set. For exam- ple, an AlternativeCapabilitySet listing {G.711, G.723.1, G.728} means that the terminal can operate in any one of those audio modes, but not more than one. These AlternativeCapabilitySet structures are grouped into simultaneous- Capabilities structures. Each simultaneousCapabilities structure indi- cates a set of modes the terminal is capable of using simultaneously. For example, a simultaneousCapabilities structure containing the two AlternativeCapabilitySet structures {H.261, H.263} and {G.711, G.723.1, G.728} means that the terminal can operate either of the video codecs simultaneously with any one of the audio codecs. The simultaneousCapa- bilities set {{H.261}, {H.261, H.263}, {G.711, G.723.1, G.728} } means the terminal can operate two video channels and one audio channel simul- taneously: one video channel per H.261, another video channel per either H.261 or H.263, and one audio channel per either G.711, G.723.1, or G.728. The capabilities are defined by selecting first a capability type, such as VideoCapability, AudioCapability, DataApplicationCapability or ConferenceCapability. H.245 does not provide identifiers for capability types, but simply define them as alternatives in the ASN.1 "Capability" Huitema [Page 3] Internet draft Megaco capacities with SDP 20 May 1999 type of the syntax. Each specific capability, in turn, is defined by its own ASN.1 type, such as for example: VideoCapability ::=CHOICE { nonStandard NonStandardParameter , h261VideoCapability H261VideoCapability, h262VideoCapability H262VideoCapability, h263VideoCapability H263VideoCapability, is11172VideoCapability IS11172VideoCapability, ... } The most used types, such as for example "H261VideoCapability" are explicitly defined by their own ASN.1 data type, such as: H261VideoCapability ::=SEQUENCE { qcifMPI INTEGER (1..4) OPTIONAL, -- units 1/29.97 Hz cifMPI INTEGER (1..4) OPTIONAL, -- units 1/29.97 Hz temporalSpatialTradeOffCapability BOOLEAN, maxBitRate INTEGER (1..19200), -- units of 100 bit/s stillImageTransmission BOOLEAN, -- annex D of H.261 ... } Less used types and extensions can used the NonStandardParameter struc- ture, which is composed of a parameter identifier (NonStandardIdentif- ier, generally an ASN.1 Object Identifier) and of an unstructured object string. 1.2. SDP extension procedures SDP has been designed to be extensible in three ways: * New media types can be registered to the IANA, using the procedure defined for MIME media types. * New encoding types can be registered to the IANA, * New session and media attributes can be defined. The extensions procedures have two effects. They enable the systems to evolve with the advent of new technology, but they also enable intero- perability between old and new systems. For example, one could define a new media type for, for example, a smell carrying channel, and use this Huitema [Page 4] Internet draft Megaco capacities with SDP 20 May 1999 definition to invite a partner to a truly ecstatic multimedia session, as in the following description: v=0 o=chuitema 2890844526 2890842807 IN IP4 192.96.41.1 c=IN IP4 224.2.17.12/127 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=smell 32416 udp wperfume If the invited partner is equipped to handle the new media, it will pro- vide its own address and port in the response. If it is not equipped to do so, it will be able to parse the message and to understand that the "m=smell" line refers to an unsupported media. It can still set up the session, using only the audio and video media. The proposed encoding types, when using SDP, are defined by the RTP pay- load type. The values "0" and "31" in the previous example correspond to payload type reserved in the standard Audio Video profile (RFC 1890, whose revision is in progress). The value 0 is assigned to "PCMU" (G.711 with mu law encodings) and the value 31 is assigned to H.261. New algo- rithms can be defined using the "negotiated payload type" facility. For example, if Telcordia Technologies defined a new audio coding scheme for HiFi audio and reserved the corresponding name "TThifi", one could issue an invite message that carried a list of proposed codecs such as: v=0 o=chuitema 2890844526 2890842807 IN IP4 192.96.41.1 c=IN IP4 224.2.17.12/127 m=audio 49170 RTP/AVP 98 0 a=rtpmap:98 TThifi/44100/16 The "rtpmap" attribute, in this example, provides a complete definition of the non standard payload type "98." The general form of an rtpmap attribute is: a=rtpmap: / [/] The encoding parameters are specific to each media. If the invited partner is equipped to handle the new encoding, it can use it in RTP packets. If it is not equipped to do so, it will be able to parse the message and to choose the next alternative, in our case PCMU. Huitema [Page 5] Internet draft Megaco capacities with SDP 20 May 1999 According to the SDP specification, "attributes are the primary means for extending SDP." "Attributes that will be commonly used can be registered with IANA(see Appendix B). Unregistered attributes should begin with "X-" to prevent inadvertent collision with registered attri- butes. In either case, if an attribute is received that is not under- stood, it should simply be ignored by the receiver." 2. Providing capability negotiation in Megaco The first difference between H.245 and SDP is the need to support a "capability exchange" procedure. The exchange procedure itself cannot be supported in SDP, which only defines format. We propose to support it through a combination of SDP and the Megaco audit procedure. We may expect that capacities will be mostly static, and that the MGC will in practice only need to query the MG at infrequent intervals. However, we must define a general procedure that can be used, if needed, on a call by call basis. 2.1. Mapping of the Capability Exchange parameters using SDP In order to map the Capability Exchange parameters using SDP, we need to provide mappings for: * Individual capacities, * Simultaneous Capabilities, * Alternative Capability Set . We will detail the proposed mappings in the following subsections. 2.1.1. Mapping of individual capacities into SDP The definition of audio, video or data capacities in H.245 varies from the very simple to the fairly complex. Most "audio capacities" are sim- ply defined as an algorithm type and the number of audio frames that can be supported per packet. Some require more sophistication, such as the specification of the mode values for G.723 annex C. Video capacities, on the other hand, are defined by complex set of parameters corresponding to the various encoding options. The capability to support a given algo- rithm is expressed in SDP by: * Placing a reference to the standard payload type associated with the algorithm in the corresponding "media" line, * Or by placing a reference to a dynamic payload type in a media line, and by defining the corresponding algorithm type and Huitema [Page 6] Internet draft Megaco capacities with SDP 20 May 1999 algorithm parameters in the "rtpmap" attribute. In addition to the type, the RTPMAP attribute systematically defines the clock rate used for the media, and may also include algorithm specific attribute. It does not generally include a count of frame per packet, because stations are in most cases expected to use the default value defined for the media. Non default value could be provided by using the "ptime" attribute. The following table provide a list of audio and video formats supported in H.323, with the RTP/AVP equivalence when it is defined: Huitema [Page 7] Internet draft Megaco capacities with SDP 20 May 1999 ________________________________________________________________ | H.245 capa. | AVP # | Description | |______________|____________|___________________________________| | g711Alaw64k, | PCMA 8 | No difference in RTP | | g711Alaw56k | | between 56 and 64 kbps. | |______________|____________|___________________________________| | g711Ulaw64k, | PCMU 0 | No difference in RTP | | g711Ulaw56k | | between 56 and 64 kbps. | |______________|____________|___________________________________| | g722-64k, | G722 9 | The RTP/AVP code point | | g722-56k, | | only refers to the 64 kbps | | g722-48k | | encoding. | |______________|____________|___________________________________| | g7231, | G723 4 | The RTP/AVP code point is | | | | common to all variants | | | | of G.723. Support of low | | | | bit rate, high bit rate | | | | and comfort noise is | | | | mandatory in receivers. | | g7231AnnexC- | | The RTP/AVP profiles don't | | Capability | | include a specific code point. | |______________|____________|___________________________________| | g728 | G728 15| | |______________|____________|___________________________________| | g729, | G729 18| According to RTP/AVP, a | | g729AnnexA, | | terminal that supports G729 | | g729wAnnexB, | | shall be capable of receiving | | g729Annex- | | packets composed of AnnexA | | AwAnnexB | | and AnnexB frames. The payload | | | | name G729B is reserved for flows | | | | that would only include | | | | comfort noise. | |______________|____________|___________________________________| | is11172Audio-| MPA 14| MPEG audio encoding in | | Capability, | | RTP is defined in RFC 2038, | | is13818Audio-| | "RTP payload format for | | Capability | | MPEG1/MPEG2 video," which also | | | | defines video encodings (MPV). | |______________|____________|___________________________________| | gsmFullRate, | GSM 3 | Current RTP/AVP specification | | gsmHalfRate, | | only refers to the GSM "full | | gsmEnhanced- | | rate" encoding (13 kbps). | | FullRate | | | |______________|____________|___________________________________| Huitema [Page 8] Internet draft Megaco capacities with SDP 20 May 1999 ___________________________________________________________ | H.245 capability | AVP # | Description | |_______________________|___________|______________________| | h261VideoCapability | H261 31| | | h262VideoCapability | | | | h263VideoCapability | H263 34| | |_______________________|___________|______________________| | is11172VideoCapability| MPV 32| MPEG Video, as | | | | defined in RFC 2038.| |_______________________|___________|______________________| We should note that the RTP/AVP specification defines types that have no equivalent in H.245, such as: _____________________________________________________________ | AVP | # | Description | |________|____|______________________________________________| | 1016 | 1 | | | G726-32| 2 | ADPCM, G.726 | | DVI4 | 5 | Intel's DVI format, 4 bits adaptative, 8KHz | | VDVI | | Variable length DVI | | DVI4 | 6 | 16 Khz | | DVI4 | 16| 11.025 KHz | | DVI4 | 17| 22.050 KHz | | LPC | 7 | Linear Prediction Coding. | | L16 | 10| Linear 16 bits 44.1 KHz, stereo | | L16 | 11| Linear 16 bits 44.1 KHz, mono | | CN | 19| Comfort noise, 8 KHz. | | CelB | 25| Cell-B format, defined by SUN | | JPEG | 26| JPEG video. | | nv | 28| Network Video format, defined by Xerox/PARC.| | MP2T | 33| MPEG stream, mixing audio and video, | | | | as defined in RFC 2038. | | RED | 77| Redundancy audio encodings | |________|____|______________________________________________| These capacities will have to be translated into "non standard" audio or video H.245 capabilities, using the NonStandardParameter data type, which is generally composed of an identifier and an octet string. A gen- eric support could be achieved by: * Providing an algorithmic procedure to map an IANA registered name, such as "nv", into a NonStandardParameter identifier. Currently, the identifiers can only be defined as "Object Identifiers." Inter- working would be greatly eased if a alternate "textual identifier" was allowed. Huitema [Page 9] Internet draft Megaco capacities with SDP 20 May 1999 * Providing an algorithmic procedure to map the SDP description into the NonStandardParameter octet string, possibly by mapping the text of the RTPMAP attribute into the octet string. Data capacities are generally not expressed using the RTP payload for- mat. In SDP, a data stream will be defined by its own media line, as in for example: Huitema [Page 10]