[Live-devel] Regarding QoS and RTPTransmissionStat

[MANDJUKOWSKI Esteban]

Thanks for the fast answer, and sorry for my earlier imprecisions.

> I’m not sure what you mean by “duplicates”.  The “RTPTransmissionStats” database is indexed by SSRC, which (the “SSRC()” field in “RTPTransmissionStats”) should be different for each client.

The "SSRC()" field is indeed different for each entry, the duplicates arise from how I gather the RTPTransmissionStats.

For example, let's say I have two clients, connected to the same stream 'live'.
The repetitive task in my dashboard currently does : 

void QoSDashboard::poll()
{
    for (QoSRTSPClientSession *session : fSessions)
    {
        session->poll();
    }
}

where session->poll() is the method from the previous message : 

void QoSRTSPClientSession::poll()
for (int i = 0; fNumStreamStates; i++) {
        fStreamStates[i].subsession->getRTPSinkandRTCP(fStreamStates[i].streamToken, rtpSink, rtcp);
        RTPTransmissionStatsDB::Iterator iter(rtpSink->transmissionStatsDB());
        RTPTransmissionStats *stats = nullptr;
        while ((stats = iter.next()) != NULL) {
            // add to a vector of Snapshots if it's related to the current QoSRTSPClientSession
       }
}

Since both clients are connected to the same stream (and so the same RTPSink, since reuseFirstSource is True), I do iterate twice over every RTPTransmissionStats instance that is present in the RTPTransmissionStatsDB, because each QoSRTSPClientSession sees the entire RTPTransmissionStatsDB when looping over it.

So the issue here might be that I am storing the QoSRTSPClientSession instances instead of the RTPSinks in my QoSDashboard. 
Is it possible to access active RTPSinks in order to loop over them rather than RTSPClientSession ? This would definitely solve the "duplicates" issue.

> I’m not sure what you are asking for here.  There is not a 1-to-1 mapping from “RTSPClientSession” to “RTSPClientConnection”, because it is possible for multiple RTSP TCP connections (each represented by a 
> “RTSPClientConnection”) to be used to perform operations within a single RTP Session (“RTSPClientSession”).  

Ah, I wrote RTSPClientConnection where I meant to write RTSPClientSession. My mistake about that.

> What specifically do you want to do?  

I meant to ask about a way to tell apart the RTPTransmissionStats related to a QoSRTSPClientSession instance : 

For example,

RTPTransmissionStatsDB :

RTPTransmissionStats instance1      <---- this instance is a RR from a ServerMediaSession that is in one of my fStreamStates[i].subsession
RTPTransmissionStats instance2      <---- this one is not, so we should ignore her when polling QoS
RTPTransmissionStats instance3     
RTPTransmissionStats instance4
RTPTransmissionStats instance5      <---- this one is a RR from a ServerMediaSession that is in one of my fStreamStates[i].subsession
RTPTransmissionStats instance6
...

How can I tell apart which instances of RTPTransmissionStats that are in the RTPTransmissionDB are for this particular ClientSession and which are from other sessions ?


> (Note that you can use the  “RTPTransmissionStats::lastFromAddress()” method to get the most recent IP address and port used by each SSRC.)

So, using IP address + port from “RTPTransmissionStats::lastFromAddress()” and comparing them to IP address and port we stored in the handleCmd_SETUP (or PLAY ?) method of the RTSPClientSession would be the way to differentiate between other ClientSession's statistics and ours ?
Although this works for UDP, it can not for TCP (and HTTP too I guess ?).

> Sorry, I don’t have a solution here.  (Once again, a reminder that RTP/RTCP-over-TCP should be used only if you have a firewall - between the server and client - that blocks UDP packets.)

Since some clients might be behind firewalls (or soon-to-be), I do not have much of a choice here.

Best regards,
MANDJUKOWSKI Esteban