|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
## MMUSICwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 12, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
## MMUSICwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
## MMUSICwg
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the MMUSIC working group -- updated on March 27, 2008 --
is reported below.
|
|
|
|
The Multiparty MUltimedia SessIon Control (MMUSIC)
working group was
chartered to develop protocols to support Internet teleconferencing and
multimedia communications. These protocols are now reasonably mature,
and many have received widespread deployments. The group has revised
some of these protocols in the light of implementation experience and
additional demands that have arisen from other WGs (such as AVT, SIP,
and SIPPING). It is focused on using and negotiating mechanisms such
STUN and TURN in order to enable media sessions to traverse Network
Address Translators NATs, and on new means to exchange SDP capabilities.
Multimedia communications protocols use a common platform to express
media and session descriptions: the Session Description Protocol, SDP.
The many uses of SDP have led to (requests for) numerous extensions and
have led to recognition of several flaws in the protocol design, some of
which were addressed in the revision of SDP. In spite of these, it is
widely deployed.
The current aims of the working group include the following:
|
|
| - |
To support the establishment of multi-party multimedia sessions across
NATs, MMUSIC will define an Internet Connectivity Establishment
protocol (ICE). This will define several SDP extensions to work with
NATs for media sessions carried over both UDP and TCP.
|
| - |
Various extensions to SDP will be pursued to remedy the most urgent of
SDP's shortcomings. These will be limited and include adding support
for limited but generic capability negotiations in SDP, defining the
means to select QoS mechanisms to use for a particular media stream,
enabling file transfer via the SDP Offer/Answer model, and support
for
media loopback.
With the exception of these specific items, only extensions within the
existing SDP framework will be done (e.g. registering new codecs and
defining parameters for them, extending SDP to include new address
families).
|
| - |
to maintain and revise the specification of the Real Time Streaming
Protocol (RTSP), including fixes and clarifications based on
implementation experience. The revised RTSP specification will be
re-issued as a Proposed Standard RFC. We will also document how RTSP
can be used in the presence of NAT boxes.
|
| - |
The MMUSIC work items will be pursued in close coordination with other
IETF WGs including AVT, SIP, SIPPING, SIMPLE, XCON, and BEHAVE, as well
as others where appropriate such as NSIS.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
## MMUSICwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
## MMUSICwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
mmusic-ice-tcp-06
AD is watching
Feb 25, 2008
(20 p.)
[pdf(2)]
[html]
|
J. Rosenberg |
|
TCP Candidates with Interactive Connectivity Establishment (ICE) |
|
Interactive Connectivity Establishment (ICE) defines a mechanism for
NAT traversal for multimedia communication protocols based on the
offer/answer model of session negotiation. ICE works by providing a
set of candidate transport addresses for each media stream, which are
then validated with peer-to-peer connectivity checks based on Session
Traversal Utilities for NAT (STUN). ICE provides a general framework
for describing candidates, but only defines UDP-based transport
protocols. This specification extends ICE to TCP-based media,
including the ability to offer a mix of TCP and UDP-based candidates
for a single stream.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
## MMUSICwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
mmusic-
connectivity-
precon-04
ID Exists
Jan 23, 2008
(18 p.)
[pdf(2)]
[html]
|
F. Andreasen
G. Camarillo
D. Oran
D. Wing |
|
Connectivity Preconditions for Session Description Protocol Media Streams |
|
This document defines a new connectivity precondition for the Session
Description Protocol (SDP) precondition framework. A connectivity
precondition can be used to delay session establishment or
modification until media stream connectivity has been successfully
verified. The method of verification may vary depending on the type
of transport used for the media. For unreliable datagram transports
such as UDP, verification involves probing the stream with data or
control packets. For reliable connection-oriented transports such as
TCP, verification can be achieved simply by successful connection
establishment or by probing the connection with data or control
packets, depending on the situation.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
mmusic-decoding-
dependency-01
ID Exists
Feb 25, 2008
(16 p.)
[pdf(2)]
[html]
|
T. Schierl
S. Wenger |
|
Signaling media decoding dependency in SDP |
This memo defines semantics that allow for signaling the decoding
dependency of different media descriptions with the same media type in
the Session Description Protocol (SDP). This is required, for example,
if media data is separated and transported in different network streams
as a result of the use of a layered or multiple descriptive media coding
process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be
used in conjunction with RFC 3388 entitled "Grouping of Media Lines in
the Session Description Protocol". In addition, an attribute is
specified describing the relationship of the media streams in a "DDP"
group indicated by media identification attribute(s) and RTP payload
type(s).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
mmusic-file-
transfer-mech-07
ID Exists
Mar 27, 2008
(46 p.)
[pdf(2)]
[html]
|
M. Garcia-Martin
M. Isomaki
G. Camarillo
S. Loreto
P. Kyzivat |
|
A SDP Offer/Answer Mechanism to Enable File Transfer |
|
This document provides a mechanism to negotiate the transfer of one
or more files between two endpoints by using the Session Description
Protocol (SDP) offer/answer model specified in RFC 3264. SDP is
extended to describe the attributes of the files to be transferred.
The offerer can either describe the files it wants to send, or the
files it would like to receive. The answerer can either accept or
reject the offer separately for each individual file . The transfer
of one or more files is initiated after a successful negotiation.
The Message Session Relay Protocol (MSRP) is defined as the default
mechanism to actually carry the files between the endpoints. The
conventions on how to use MSRP for file transfer are also provided in
this document.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
mmusic-
media-loopback-08
ID Exists
Jan 14, 2008
(34 p.)
[pdf(2)]
[html]
|
K. Hedayat
P. Jones
A. Roychowdhury
C. SivaChelvan
N. Stratton
N. Venna |
| An Extension to SDP for Media
Loopback |
|
The wide deployment of Voice over IP (VoIP), Real-time Text and
Video over IP services has introduced new challenges in managing
and maintaining voice/real-time Text/video quality, reliability,
and overall performance. In particular, media delivery is an area
that needs attention. One method of meeting these challenges is
monitoring the media delivery performance by looping media back to
the transmitter. This is typically referred to as "active
monitoring" of services. Media loopback is especially popular in
ensuring the quality of transport to the edge of a given VoIP,
Real-time Text or Video over IP service. Today in networks that
deliver real-time media, short of running 'ping' and 'traceroute'
to the edge, service providers are left without the necessary tools
to actively monitor, manage, and diagnose quality issues with their
service. The extension defined herein adds new SDP media
attributes which enables establishment of media sessions where the
media is looped back to the transmitter. Such media sessions will
serve as monitoring and troubleshooting tools by providing the
means for measurement of more advanced VoIP, Real-time Text and
Video Over IP performance metrics.
|
|
|
|
|
|
|
|
|
|
|
| | |
mmusic-media-path-
middleboxes-00
ID Exists
Jan 17, 2008
(19 p.)
[pdf(2)]
[html]
|
B. Stucker
H. Tschofenig |
|
Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path |
Middleboxes are defined as any intermediary box performing functions
apart from normal, standard functions of an IP router on the data
path between a source host and destination host. Two such functions
are network address translation and firewalling.
When Application Layer Gateways, such as SIP entities, interact with
NATs and firewalls, as described in the MIDCOM architecture, then
problems may occur in the transport of media traffic when signaling
protocol interaction takes place along the media path, as it is the
case for recent key exchange proposals (such as DTLS-SRTP). This
document highlights problems that may arise. Unfortunately, it is
difficult for the end points to detect or predict problematic
behavior and to determine whether the media path is reliably
available for packet exchange.
This document aims to summarize the various sources and effects of
NAT and firewall control, the reasons that they exist, and possible
means of improving their behavior to allow protocols that rely upon
signaling along the media path to operate effectively.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
mmusic-qos-
identification-01
ID Exists
Jan 23, 2008
(10 p.)
[pdf(2)]
[html]
|
J. Polk
S. Dhesikan
G. Camarillo |
|
Quality of Service (QoS) Mechanism Selection in the Session Description
Protocol (SDP) |
|
The offer/answer model for SDP assumes that endpoints establish,
somehow, the QoS required for the media streams they establish.
Endpoints in closed environments typically agree out of band (e.g.,
using configuration information) which QoS mechanism to use.
However, on the Internet, there is more than one QoS service
available. Consequently, there is a need for a mechanism to
negotiate which QoS mechanism to use for a particular media stream.
This document defines such a mechanism.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
mmusic-
rfc2326bis-18
ID Exists
May 5, 2008
(246 p.)
[pdf(2)]
[html]
|
H. Schulzrinne
A. Rao
R. Lanphier
M. Westerlund
A. Narasimhan
M. Stiemerling |
|
Real Time Streaming Protocol 2.0 (RTSP) |
This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in
RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
mmusic-
rfc4566bis-00
ID Exists
Dec 6, 2007
(48 p.)
[pdf(2)]
[html]
|
M. Handley
V. Jacobson
C. Perkins |
|
SDP: Session Description Protocol |
This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation.
The changes relative to RFC 4566
are limited to essential corrections, and are outlined in Section 10
of this memo.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
mmusic-sdp-
capability-
negotiation-08
ID Exists
Dec 11, 2007
(79 p.)
[pdf(2)]
[html]
|
F. Andreasen |
|
SDP Capability Negotiation |
The Session Description Protocol (SDP) was intended for describing
multimedia sessions for the purposes of session announcement,
session invitation, and other forms of multimedia session
initiation. SDP was not intended to provide capability indication or
capability negotiation, however over the years, SDP has seen
widespread adoption and as a result it has been gradually extended
to provide limited support for these, notably in the form of the
offer/answer model defined in RFC 3264. SDP and its current
extensions do not define how to negotiate one or more alternative
transport protocols (e.g. RTP profiles) or attributes. This makes it
difficult to deploy new RTP profiles such as secure RTP or RTP with
RTCP-based feedback, negotiate use of different security keying
mechanisms, etc. It also presents problems for some forms of media
negotiation.
The purpose of this document is to address these shortcomings by
extending SDP with capability negotiation parameters and associated
offer/answer procedures to use those parameters in a backwards
compatible manner.
The document defines a general SDP Capability Negotiation framework.
It also specifies how to provide attributes and transport protocols
as capabilities and negotiate them using the framework. Extensions
for other types of capabilities (e.g. media types and media formats)
may be provided in other documents.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
mmusic-sdp-
capability-
negotiation-
reqts-01
ID Exists
(Recently Expired)
Mar 4, 2007
(23 p.)
[pdf(2)]
[html]
|
F. Andreasen |
|
SDP Capability Negotiation:
Requirements and Review of Existing Work |
|
The Session Description Protocol (SDP) was intended for describing
multimedia sessions for the purposes of session announcement, session
invitation, and other forms of multimedia session initiation. SDP was
not intended to provide capability indication or capability
negotiation, however over the years, SDP has seen widespread adoption
and as a result it has been gradually extended to provide limited
support for these. SDP and its current extensions however do not
have, for example, the ability to negotiate one or more alternative
transport protocols (e.g. RTP profiles) which makes it particularly
difficult to deploy new RTP profiles such as secure RTP and RTP with
RTCP-based feedback. The purpose of this document is to identify a
set of requirements for SDP Capability Negotiation and evaluate
existing work in this area. The document does not provide any
solutions to SDP Capability Negotiation.
|
|
|
|
|
|
|
|
|
|
|
| | |
mmusic-sdp-dtls-00
ID Exists
Jan 23, 2008
(8 p.)
[pdf(2)]
[html]
|
J. Fischl
H. Tschofenig |
|
SDP Indicators for Datagram Transport
Layer Security (DTLS) |
|
This specification defines how to use the Session Description
Protocol (SDP) to signal that media will be transported over Datagram
Transport Layer Security (DTLS) or where the SRTP security context is
established using DTLS and. It reuses the syntax and semantics for
an SDP 'fingerprint' attribute that identifies the certificate which
will be presented during the DTLS handshake.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
mmusic-sdp-media-
capabilities-03
ID Exists
Feb 25, 2008
(37 p.)
[pdf(2)]
[html]
|
R. Gilman
R. Even
F. Andreasen |
|
SDP media capabilities Negotiation |
|
Session Description Protocol (SDP) capability negotiation provides a
general framework for indicating and negotiating capabilities in SDP.
The base framework defines only capabilities for negotiating
transport protocols and attributes. In this document, we extend the
framework by defining media capabilities that can be used to
negotiate media types and their associated parameters. This
extension is designed to map easily to existing and future SDP media
attributes.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
mmusic-sdp-source-
attributes-01
ID Exists
Feb 25, 2008
(19 p.)
[pdf(2)]
[html]
|
J. Lennox
J. Ott
T. Schierl |
|
Source-Specific Media Attributes in SDP |
|
The Session Description Protocol provides mechanisms to describe
attributes of multimedia sessions and of individual media streams
(e.g., Real-time Transport Protocol (RTP) sessions) within a
multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream. This document
defines a mechanism to describe RTP media sources, identified by
their Synchronization Source Identifiers (SSRCs), in SDP, associate
attributes with these sources, and express relationships among
sources. It also defines several source-level attributes which can
be used to describe properties of media sources.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
## MMUSICwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
begen-mmusic-
fec-grouping-
issues-00
ID Exists
Feb 14, 2008
(12 p.)
[pdf(2)]
[html]
|
A. Begen |
|
FEC Grouping Issues in SDP |
|
The Session Description Protocol (SDP) currently supports grouping
media lines. SDP also has semantics defined for grouping the
associated source and Forward Error Correction (FEC)-based repair
flows. However, the existing specifications have strict requirements
that severely limit the use of the new features that are currently
under development in the FECFRAME WG. These new features will allow
applications to use FEC in a more flexible way but they require
changes in the current specifications. This document provides a list
of the required changes and discusses potential approaches to make
these changes.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
garcia-mmusic-
sdp-collaboration-00
ID Exists
Feb 18, 2008
(23 p.)
[pdf(2)]
[html]
|
M. Garcia-Martin
J. Ott |
|
SDP Extensions and Conventions for Collaboration Applications |
|
The Session Description Protocol (SDP) is typically used in
conjunction with the Session Initiation Protocol (SIP) for
establishing multimedia sessions on the Internet. Typically these
sessions include audio, video or messaging streams. Rich
collaboration applications can complete these multimedia sessions,
including view sharing with remote manipulation, co-web browsing, and
file transfer.This document discusses rich collaboration between two
endpoints and provides conventions and extension to SDP to enable
these applications.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
garcia-mmusic-
sdp-cs-01
ID Exists
Apr 15, 2008
(26 p.)
[pdf(2)]
[html]
|
M. Garcia-Martin
S. Veikkolainen |
|
Conventions for the Use of SDP for
Circuit-Switched Bearer Connections in the PSTN |
|
This memo describes use cases, requirements, and protocol conventions
for using the Session Description Protocol (SDP) Offer/Answer model
for establishing circuit-switched bearer connections in the Public
Switched Telephone Network (PSTN). Additionally, this memo proposes
conventions for using SDP and the SDP capability negotiation
framework for expressing those circuit-switched bearer connections as
alternatives to packet-switched streams.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
loreto-mmusic-
sctp-sdp-00
ID Exists
Feb 17, 2008
(7 p.)
[pdf(2)]
[html]
|
S. Loreto
G. Camarillo |
|
SCTP-Based Media Transport in SDP |
|
Stream Control Transmission Protocol (SCTP) provides a realiable
communication channel between two end-hosts in may way similar to
TCP. This document describes how to express media transport over
SCTP using the Session Description Protocol (SDP). It defines the
SDP 'SCTP' protocol identifier.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
marjou-mmusic-
sdp-rtsp-01
ID Exists
Feb 25, 2008
(14 p.)
[pdf(2)]
[html]
|
X. Marjou
J. Lindquist
P. Rajagopal
M. Said
S. Ganesan |
|
SDP Offer/Answer Model For Media Control Protocol |
|
This draft presents an approach to content on demand that relies on a
session management protocol and SDP offer/answer model to
establish media control and media delivery flows. This approach would
be beneficial for some applications such as IPTV or applications that
require a mix of real-time and streaming flows.
|
|
|
|
|
|
|
|
|
|
|
| | |
polk-mmusic-
dscp-attribute-02
ID Exists
Feb 23, 2008
(13 p.)
[pdf(2)]
[html]
|
J. Polk |
|
Configuring the Differentiated Services Codepoint of
SDP Established Media Streams |
|
The Session Description Protocol (SDP) offer/answer model currently
has no mechanism for dynamic configuration of the Differentiated
Services Codepoints (DSCP) for the media streams endpoints
establish. This document creates such a mechanism within SDP, as
granular as at the media stream level where more than one stream can
be in an offer/answer exchange, to set a particular DSCP for the
desired Per Hop Behavior (PHB) of a media stream. This same
mechanism can change a DSCP of an existing stream based on dynamic
network conditions.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
rosenberg-mmusic-
ice-nonsip-00
ID Exists
Feb 15, 2008
(16 p.)
[pdf(2)]
[html]
|
J. Rosenberg |
|
NICE: Non Session Initiation Protocol (SIP) usage of Interactive
Connectivity Establishment (ICE) |
|
Interative Connectivity Establishment (ICE) has been specified as a
NAT traversal mechanism for protocols based on the offer/answer
exchange model. In practice, only the Session Initiation Protocol
(SIP) has been based on the offer/answer model. This document
defines a SIP independent subset of ICE, called NICE, which can be
used with any protocol wishing to establish a direct host-to-host
relationship through NAT. Protocol specifications need only
reference this document, and include the object defined here in their
messages, in order to achieve NAT traversal.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
saito-mmusic-
sdp-ike-02
ID Exists
Dec 3, 2007
(21 p.)
[pdf(2)]
[html]
|
M. Saito
D. Wing |
|
Media Description for IKE in the Session Description Protocol (SDP) |
|
This document extends the protocol identifier of SDP so that it could
negotiate the use of IKE for media session in SDP offer/answer model.
And it also specifies the method to boot up IKE and generate IPsec SA
using self-signed certificate under the mechanism of comedia-tls.
This document extends RFC 4572. In addition, it defines a new
attribute "udp-setup", which is similar to "setup" attribute defined
in RFC 4145, to enable endpoints to negotiate their roles in the IKE
session.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
volmedo-mmusic-
sdp-wsdl-00
ID Exists
(Recently Expired)
Nov 5, 2007
(15 p.)
[pdf(2)]
[html]
|
V. Olmedo
V. Villagra
J. Burgos
G. Gallizo |
|
The Session Description Protocol (SDP) WSDL Attribute |
|
This document defines a new Session Description Protocol (SDP) media-level
attribute: 'wsdl'. The 'wsdl' attribute allows for a user
running Web Services to let a potential client know the Uniform
Resource Identifier (URI) where the Web Service Description Language
file (WSDL) describing the service can be obtained. The WSDL file
describes the public interface offered by the Web Service and allows
the client to consume the service. It also defines the SDP proto
value 'TCP/HTTP', needed for this type of communication.
|
|
|
|
|
|
|
|
|
|
|
| | |
walsh-mmusic-
img-envelope-07
ID Exists
Sep 6, 2007
(34 p.)
[pdf(2)]
[html]
|
R. Walsh
J-P. Luoma
J. Peltotalo
S. Peltotalo
J. Greifenberg |
|
The IMG Envelope |
|
This document defines the metadata transfer envelope for Internet
Media Guides (IMGs). IMG metadata describes files, resources and
multimedia programs available for streaming or downloading via
multicast or unicast. IMG metadata is encapsulated into, or
associated with, an IMG envelope before actual transport. The IMG
envelope is a structure providing independence between IMG transport
protocols and different metadata formats. This specification
provides the IMG envelope instantiation using structured Extensible
Markup Language (XML) syntax, both as a wrapper in which to embed an
IMG metadata object and as a distinct object to associate with a
distinct IMG metadata object.
|
|
|
|
|
|
|
|
|
|
|
|
|
