Next: , Previous: Payload Types and Formats, Up: Using ccRTP

4.3 Participants And Sources of Synchronization

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.