One document matched: draft-huitema-megaco-discuss-sdp-00.txt
Internet Engineering Task Force Christian Huitema
INTERNET DRAFT Telcordia Technologies
May 20, 1999 Expires: November 20, 1999
<draft-huitema-megaco-discuss-sdp-00.txt>
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:<payload type> <encoding name>/<clock rate>
[/<encoding parameters>]
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]
| PAFTECH AB 2003-2026 | 2026-04-22 19:07:46 |