Next: RTP Packets Extensions, Previous: Payload Types and Formats, Up: Using ccRTP
In GNU ccRTP, there are classes that represent RTP
applications (RTPApplication), participants
(Participant), synchronizacion sources (SyncSource) and
RTP sessions (RTPSession). The relations among these entities
are shown in the following diagram:
An RTP application establishes a space of CNAME identifiers, whereas an RTP session establishes a space of SSRC identifiers.
For each source of synchronization seen in an RTP session, a
SyncSource object identified by a SSRC numeric identifier is
created. Thus, at the beginning of an RTP session there are
no SyncSource objects related. Note that, if the local source
sends packets to itself during an RTP session, a
SyncSource object will be created for it.
The list of sources of synchronization identified in an RTP session
can be retrived through STL-like iterators of type
RTPSession::SyncSourcesIterator, as shown in the following
example.
// rx is an RTPSession object
RTPSession::SyncSourcesIterator it;
for (it = rx.begin() ; it != rx.end(); it++) {
const SyncSource &s = *it;
cout << s.getID();
if ( s.isSender() )
cout << "is an active sender";
cout << endl;
}
|
Note RTPSession::SyncSourcesIterator is a const iterator.
When using RTCP, it is possible to associate several synchronization
source objects to a participant in the multimedia session, which is
represented through the association between Participant and
SyncSource objects. The participant object linked to a source
of synchronization can be retrieved through the
SyncSource::getParticipant() method, as the following examples
shows:
// s is a source of synchronization object (SyncSource)
Participant *p = s.getParticipant();
cerr << p->getSDESItem(SDESItemTypeCNAME) << endl;
|
When RTCP is not being used or the CNAME identifier corresponding to a
synchronization source has not been received yet, the participant
associated with a synchronization source is not known. In these cases,
the method SyncSource::getParticipant() will return a NULL
pointer. On the contrary, a participant is always related to a
synchronization source at least. It can also be related to more than
one synchronization source (for instance, when a participant in a
videoconference sends two video streams from two different
chameras). Note that, if the local source sends data and control
packets to itself, a Participant object will be created for it.
Thus, the SyncSource::getParticipant provides a facility for
inter-media synchronization.
The association of RTP sessions and participants with
RTPApplication objects makes it possible to implement several
“RTP applications” in the same application or process, each one
having a separate CNAME space. By default, all RTP sessions
are associated to an RTP application provided by the global
method defaultApplication(). The local CNAME for the default
application is guessed from the user and machine name, as specified in
RFC 3550.
However, other applications may be created through the constructor
RTPApplication::RTPApplication(const std::string& cname). RTP sessions are associated with applications other
than the default via an optional constructor parameter.
Similarly to the list of synchronization sources, the list of
participants in a session can be retrieved using iterators of type
RTPApplication::ParticipantsIterator, see the following
example, which shows the list of CNAMEs of the participants in the
default application:
RTPApplication &app = defaultApplication();
RTPApplication::ParticipantsIterator ai;
for ( ai = app.begin(); ai != app.end(); ai++ ) {
const Participant &p = *ai;
cerr << p.getSDESItem(SDESItemTypeCNAME) << endl;
}
|
Note RTPApplication::ParticipantsIterator is a const iterator.
TODO: SyncSource states.