[sip-comm-dev] Question about CallSipImpl


#1

Hi Emil,

yesterday I've committed the call history implementation and tests, but I broke the cc build.
The reason Is in method CallSipImpl.removeCallParticipant :

callParticipant.setCall(null);

Is there any particular reason for this? I'm waiting for the event of removed participant and I'm expecting
that he has a sourceCall but its null.

damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hello Damencho,

Well here's my thinking: When a CALL_PARTICIPANT_REMOVED event gets fired it implies that a call participant is no longer in the source call, so it is logical for a call participant to not be among the participants of a call once this event gets fired. The getCall method of the call participant itself should also return null since the participant does not belong to the call any more and it should not advertise a non-existent relationship.

The CallParticipantEvent that's dispatched upon removal of a participant, however, has a getSourceCall() method. Wouldn't that do the trick?

Emil

Damian Minkov wrote:

···

Hi Emil,

yesterday I've committed the call history implementation and tests, but I broke the cc build.
The reason Is in method CallSipImpl.removeCallParticipant :

callParticipant.setCall(null);

Is there any particular reason for this? I'm waiting for the event of removed participant and I'm expecting
that he has a sourceCall but its null.

damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Yes, sorry I've missed that method.
Thanks :slight_smile:

Emil Ivov wrote:

···

Hello Damencho,

Well here's my thinking: When a CALL_PARTICIPANT_REMOVED event gets fired it implies that a call participant is no longer in the source call, so it is logical for a call participant to not be among the participants of a call once this event gets fired. The getCall method of the call participant itself should also return null since the participant does not belong to the call any more and it should not advertise a non-existent relationship.

The CallParticipantEvent that's dispatched upon removal of a participant, however, has a getSourceCall() method. Wouldn't that do the trick?

Emil

Damian Minkov wrote:

Hi Emil,

yesterday I've committed the call history implementation and tests, but I broke the cc build.
The reason Is in method CallSipImpl.removeCallParticipant :

callParticipant.setCall(null);

Is there any particular reason for this? I'm waiting for the event of removed participant and I'm expecting
that he has a sourceCall but its null.

damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net