[jitsi-dev] A generic way to find out who is the Caller and who is the Callee


#1

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. There
I can get the Call object and the CallPeers associated with it(using a
small hack). I can easily figure out the call direction using
the sessionInitIQ field of the CallPeerJabberImpl in case of Jingle-based
signalling. 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?

Regards,
Alexander Fedulov


#2

Hey Alexander,

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.

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.

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.

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,
Emil

···

On 04.09.12, 17:03, Alexander Fedulov wrote:


#3

Hi Emil,

thanks for your reply.

Hey Alexander,

> 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,
Emil

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?

Regards,
Alex

···

2012/9/8 Emil Ivov <emcho@jitsi.org>

On 04.09.12, 17:03, Alexander Fedulov wrote:


#4

Hey Alex,

···

On 14.09.12, 14:36, Alexander Fedulov wrote:

Hi Emil,

thanks for your reply.

2012/9/8 Emil Ivov <emcho@jitsi.org <mailto:emcho@jitsi.org>>

    Hey Alexander,

    On 04.09.12, 17:03, Alexander Fedulov wrote:
    > 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,
    Emil

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?

We use ICE with XMPP and we don't with SIP. It is hence normal that they
will have different behaviour.

You'd best get the address while the call is still active.

Cheers,
Emil