name: 4 octets
A name chosen by the person defining the set of APP packets to
be unique with respect to other APP packets this application
might receive. The application creator might choose to use the
application name, and then coordinate the allocation of subtype
values to others who want to define new packet types for the
application. Alternatively, it is recommended that others
choose a name based on the entity they represent, then
coordinate the use of the name within that entity. The name is
interpreted as a sequence of four ASCII characters, with
uppercase and lowercase characters treated as distinct.
Schulzrinne, et al Standards Track [Page 38]
RFC 1889 RTP January 1996
application-dependent data: variable length
Application-dependent data may or may not appear in an APP
packet. It is interpreted by the application and not RTP itself.
It must be a multiple of 32 bits long.
7. RTP Translators and Mixers
In addition to end systems, RTP supports the notion of "translators"
and "mixers", which could be considered as "intermediate systems" at
the RTP level. Although this support adds some complexity to the
protocol, the need for these functions has been clearly established
by experiments with multicast audio and video applications in the
Internet. Example uses of translators and mixers given in Section 2.3
stem from the presence of firewalls and low bandwidth connections,
both of which are likely to remain.
7.1 General Description
An RTP translator/mixer connects two or more transport-level
"clouds". Typically, each cloud is defined by a common network and
transport protocol (e.g., IP/UDP), multicast address or pair of
unicast addresses, and transport level destination port. (Network-
level protocol translators, such as IP version 4 to IP version 6, may
be present within a cloud invisibly to RTP.) One system may serve as
a translator or mixer for a number of RTP sessions, but each is
considered a logically separate entity.
In order to avoid creating a loop when a translator or mixer is
installed, the following rules must be observed:
o Each of the clouds connected by translators and mixers
participating in one RTP session either must be distinct from
all the others in at least one of these parameters (protocol,
address, port), or must be isolated at the network level from
the others.
o A derivative of the first rule is that there must not be
multiple translators or mixers connected in parallel unless by
some arrangement they partition the set of sources to be
forwarded.
Similarly, all RTP end systems that can communicate through one or
more RTP translators or mixers share the same SSRC space, that is,
the SSRC identifiers must be unique among all these end systems.
Section 8.2 describes the collision resolution algorithm by which
SSRC identifiers are kept unique and loops are detected.
