An APMT transport device is a special kind of device that is able to transmit and receive media data buffers and header containers. Transport devices are considered to be part of the terminal infrastructure, which means that it is not possible to transparently add a transport device to a terminal, as can be done with all other devices. The reason for this is that transport devices need to be known to the graph implementation. Support for transport device development could nevertheless be added to the APMT middleware if this should turn out to be necessary, and requires the definition of transport-specific extensions to the basic device management interfaceDevMan::DevManagement.
Transport devices have one input port and one output port to other devices within the same graph, and one network port for the transmission and reception of containers. There is no explicit definition for a network port identifier in the transport device interface. Network ports are identified by a port number and a network interface address, rather than by an integer as is the case with normal device ports. The formats set for the input and output port of the transport device must be identical. APMT transport devices are tailored to IP, and it is not possible to add a transport device to the multimedia middleware that is not based on IP. APMT transport devices are supposed to implement Internet standards for the transport of multimedia data, with examples being RTP [Schu96b] for the transport of streams and RSVP [Brad96] for resource reservation in the network.
All transport related definitions are contained in the module::Trans. This module defines types for an IP address, a transport protocol port, and a transport service access point consist-ing of an address and a port:
typedef string IpAddress;
typedef unsigned short IpPort;
struct IpTsap { IpAddress addr;
IpPort port;
};
The string format of an IP address is dotted decimal. The module ::Trans further contains the definition of a flow identifier:
struct FlowIdentifier { IpAddress srcterm;
FlowHandle handle;
};
The member handle is an unsigned long integer that the application assigns to a flow. The membersrcterm is the IP address of the terminal control of the terminal that emits the flow.
Flow identifiers are transported within special attribute headers across the network.
The transport device interface hierarchy defined in::Trans is depicted in Figure 8.7. The generic Trans::TransportDevice interface inherits from Bas::Device. It contains the definitions for the two transport device ports:
const short TpInPort = 1;
const short TpOutPort = 2;
It further contains the attributemytsap that informs about the local interface and port to which the transport device is bound, the attributedevice_mode that tells if the device is operating as
sender, receiver, or both sender and receiver, and a couple of attributes that hold transmission statistics. It also defines the operation statistics_events() that causes the transport device to emit transmission statistics events with a certain frequency. Figure 8.7 shows four transport protocol devices that inherit from Trans::TransportDevice. The interface Trans:Rmp is not defined, but is shown in order to indicate that there should be a reliable mul-ticast protocol among the transport protocols supported by the multimedia middleware. The interface Trans::Tcp represents TCP, the interface Trans::Udp UDP, and the interface Trans::Ipmcast the IP multicast protocol. The interface of the TCP device contains rea-donly attributes that inform about the remote connection endpoint, and the values of some TCP protocol parameters. The interface of the UDP device contains a single attribute telling about destinations, and the definition of an event that informs about changes in the list of destina-tions. A UDP device can be used to transmit a single container to multiple destinations, which allows to use UDP where IP multicast is not available. The interface of the IP multicast device contains an attribute telling about the IP multicast address and port, and the value of the time-to-live (ttl) parameter used for transmission. As can be seen, none of the transport device inter-faces provides control over addresses, ports and connection establishment and release. The only direct control an applet or application has over a transport device is the capability to pause transmission with a call topause() inBas::GraphObject. The most important functional-ity offered by transport device interfaces is the provision of information about transport related issues. Transport devices are controlled by the graph implementation, as will be seen later in the text.
The transport devices that inherit fromTrans::TransportDevice do not define the ini-tialization typeInit, and cannot be instantiated. They are generic in the sense that they do not impose a specific PDU format. Specific PDU formats, resource reservation protocols, and application-level transport protocols are supported by devices that inherit from the basic trans-port devices. Figure 8.7 shows the Trans::IpmcastRtp and Trans::UdpRtp that imple-ment parts of the RTP protocol, namely the RTP PDU format defined in [Schu96b] and the RTP profile for audio and video conferences with minimal control1 specified in [Schu96a]. Not supported is the RTP control protocol (RTCP), but support would need to be envisaged because it allows senders and receivers to find out about network conditions, and to implement
conges-Figure 8.7. Transport device interface hierarchy.
destinations
tion control mechanisms. In case IP multicast is used as underlying transport for RTCP it is possible to let the connection manager in the application pool receive RTCP sender and receiver report packets, which allows it to monitor the state of the network, and to centrally orchestrate counter measures in the case of congestion. As for now it is assumed that the devicesTrans::IpmcastRtp andTrans::UdpRtp do not send RTCP packets, and silently drop the ones that they receive.
The interfacesTrans::IpmcastRtp and Trans::UdpRtp only contain the definition of Init types. TheInit type of the RTP multicast device is for instance defined as follows:
struct Init {
The member mode determines if the device works as sender, receiver or both sender and receiver. The membermcast_addr is the used IP multicast address and UDP port number. It is further possible to prescribe the IP multicast time-to-live (ttl) value, and to assign a flow han-dle to the transmitted flow. The flow hanhan-dle is used together with the IP address of the terminal control in a flow identifier attribute header that is transmitted over the network.
Figure 8.8 depicts the RTP header and header extension. APMT transport devices use the marker bit that delimitates data unit boundaries and the payload type field that identifies the audio and video format as prescribed in [Schu96a]. Payload types in the range from 96 to 127 can be used by APMT to identify formats other than audio and video formats, i.e., image, ani-mation, text and graphics formats. The timestamp defined in the Cont::HeaderContainer interface is mapped to the timestamp in the RTP header. The container number in Cont::
1. This profile can be used because APMT applications are controlled via CORBA, and do not require special RTP header fields for application-level control.
Figure 8.8. The RTP header and header extension.
RTP header:
CC = number of CSRC identifiers;
M = marker bit;
PT = payload type;
sequence number = counts RTP data packets;
timestamp = reflects sampling instant (payload specific resolution);
SSRC = synchronization source identifier;
CSRC = contributing source identifiers (used by mixers);
HeaderContainer is mapped to the RTP sequence number. The synchronization source identifier (SSRC) is randomly generated as prescribed by RTP, and mapped to the source iden-tifier in Cont::HeaderContainer. The contributing sources field (CSRC) is not used, because its function will be provided by APMT attribute headers. Attribute headers are com-municated via the RTP header extension, which can be ignored by RTP receivers outside the APMT platform. APMT format keys and headers are mapped onto RTP payload types and for-mat headers. An APMT audio or video stream can therefore be received and decoded by non-APMT receivers that implement the RTP profile for audio and video conferences, like for instance the existing MBone tools. This kind of interoperability can be desirable in the case of broadcast applications.
The content of attribute headers must be marshalled into the header extension by senders, and unmarshalled by receivers. Since attribute headers are defined in IDL it seems adequate to use the Common Data Representation (CDR) of GIOP for this purpose. Marshalling code could then be automatically generated by modified IDL compilers. However, the problem with CDR is that it will waste a lot of bandwidth when used in streams. It encodes for instance an IDL boolean as an octet, and a string as a four octet length field followed by the individual characters. It is therefore more adequate to define an optimized network representation for every attribute header and to provide marshalling code for it. In order to facilitate this task it would be possible to constrain the kinds of CORBA types that can be used in attribute header definitions.
An implementation of the APMT multimedia middleware must define internal interfaces that allow to transparently add and remove RTP transport support for format and attribute headers. The way this is done is outside the scope of the APMT definitions.