thanks for your reply.
> Hi all,
> I am building a statistics reporting service into Jitsi and need to find
> out who called whom right after a Call is finished. I decided to hook up
> my statistics processing into the callEnded method of the CallManager.
This probably won't be enough. A number of things can happen before a
call ends. Other participants may have joined and left the call since it
started. You'd probably need to track all peer events.
Tracking statistics for a conference call is not envisioned in the current
scenario, so it might have been sufficient in that case. Nevertheless I
found this approach rather messy and instead of fiddling around with the
CallManager I implemented a separate bundle based on the modified
CallHistoryServiceImpl, which basically does exactly what you advice - it
can listen and react on all kinds of CallEvents and CallChangeEvents.
> There I can get the Call object and the CallPeers associated with
> it(using a small hack).
A Call simply returns the list of all its peers. There shouldn't be any
need of a hack here.
The problem is that if the logic to collect statistics is placed inside of
the callEnded(CallEvent) method, the source call, associated with the event
was already cleaned up at that point and contains no peers. The hack was to
add an additional removedPeers list field to the Call and preserve the
peers there when the fireCallPeer method received an event of
type CallPeerEvent.CALL_PEER_REMOVED (before the peers were actually
removed from the call).
> I can easily figure out the call direction using
> the sessionInitIQ field of the CallPeerJabberImpl in case of
> Jingle-based signalling.
You can figure it pretty easily from outside the Jabber and SIP packages
if you track all events.
Thanks for the hint. My service registers itself as a CallListener and gets
the incomingCallReceived and outgoingCallCreated fired, therefore now I can
track recent calls internally and differentiate between the directions.
> The problem that I am facing is that I do not
> see where I can fetch that info in case of SIP-based calls. Can someone
> give me a hint of how to figure that out? And the bigger question: is
> there maybe some generic method, which does not require downcasting the
> Call object, that I am missing?
The user interface reacts differently to outgoing and incoming calls
without a line of protocol specific code. Just make sure that you track
all call and call peer events.
Hope this helps,
It does indeed =)
I only get one more question - I have found out the following: for the
Jingle-based calls, at the point in time when the callEnded method is
called, the mediaStreamStats.getLocalIPAddress() returns null for both
incoming and outgoing calls. The remote IP is intact. For the SIP-based
calls the information is also complete. Do you have an idea what might be
the cause of this inconsistency and how to get the local ip and port?
2012/9/8 Emil Ivov <email@example.com>
On 04.09.12, 17:03, Alexander Fedulov wrote: