[jitsi-dev] Accept only one call at a time


#1

Hi,

I know you have a lot of dev going on and must not have much time but I'd appreciate it if you could give me some pointers as to how to implement a solution to the following issue:

http://java.net/jira/browse/JITSI-1034

With your overall knowledge of the source code (latest SVN) you may be able to give me hints as to which classes I should work on and the best approach/design to do so (what to check for and where when an incoming call is received, etc.).

Thanks,

Vieri


#2

Hi, Vieri!

Did you have a look at SingleCallInProgressPolicy (net.java.sip.communicator.service.protocol)? It imposes the policy to put existing calls on hold when a new one enters in progress. I thought it might be useful as an example related to tracking the recipt of incoming calls, the creation of outgoing calls and the changes in their states.

Regards,
Lyubomir


#3

Hi Lyubomir,

I noticed SingleCallInProgressPolicy but needed to ask the devs just to make sure before digging into the details.

I'll have a look at it.

Thanks,

Vieri

···

--- On Mon, 7/2/12, Lyubomir Marinov <lubo@jitsi.org> wrote:

Hi, Vieri!

Did you have a look at SingleCallInProgressPolicy
(net.java.sip.communicator.service.protocol)? It imposes the
policy to put existing calls on hold when a new one enters
in progress. I thought it might be useful as an example
related to tracking the recipt of incoming calls, the
creation of outgoing calls and the changes in their states.

Regards,
Lyubomir


#4

Could you please confirm that

CallEvent.CALL_RECEIVED
in
SingleCallInProgressPolicy

is actually the event when a call is ANSWERED, ie. right after the user clicks on the icon to accept an incoming call?
Or is it the event triggered when an incoming call is RINGING?
(I'm looking for the latter)

incomingCallReceived(CallEvent event)
in
NotificationManager
seems to be triggered when the call is RINGING.

Thanks for your help.

Vieri

···

--- On Mon, 7/2/12, Lyubomir Marinov <lubo@jitsi.org> wrote:

Hi, Vieri!

Did you have a look at SingleCallInProgressPolicy
(net.java.sip.communicator.service.protocol)? It imposes the
policy to put existing calls on hold when a new one enters
in progress. I thought it might be useful as an example
related to tracking the recipt of incoming calls, the
creation of outgoing calls and the changes in their states.


#5

На 03.07.12 15:51, Vieri написа:

Could you please confirm that

CallEvent.CALL_RECEIVED
in
SingleCallInProgressPolicy

is actually the event when a call is ANSWERED, ie. right after the user clicks on the icon to accept an incoming call?

My understanding of the source code is that net.java.sip.communicator.impl.gui.main.call.CallManager$GuiCallListener implements CallListener#incomingCallReceived(CallEvent) to display the dialog which notifies the user that a call has been received and allows answering it, hanging up i.e. I think that the user has not clicked the icon to accept the incoming call yet.


#6

Hi,

I posted some patches on JIRA:

http://java.net/jira/browse/JITSI-1034

It "works for me" but I don't know if it's the best approach (probably not).
Anyway, with the patches applied I can provision a new property:

net.java.sip.communicator.impl.protocol.SingleCallAtATimePolicy.enabled

and if enabled, Jitsi will allow only one INCOMING call at a time and reject any subsequent calls with a "busy here" code.
This is protocol-independent so even if you have several accounts (tested with SIP and XMPP) Jitsi will always restrict total active incoming calls to just one.

This feature is rather useful in a corporate environment with several accounts and the possibility of peer2peer voice communication without a PBX controlling the number of active calls for each extension/peer/registered account (or at least not *always*).

The only non-critical bug with these patches is that Jitsi throws the following exception in the log (as expected) but since it doesn't have any major consequences I'm ignoring it.

plugin.notificationwiring.NotificationManager.incomingCallReceived().1041 Error notifying for incoming call received
java.util.NoSuchElementException
  at java.util.LinkedList$ListItr.next(Unknown Source)
  at net.java.sip.communicator.plugin.notificationwiring.NotificationManager.incomingCallReceived(NotificationManager.java:1011)
  at net.java.sip.communicator.service.protocol.media.AbstractOperationSetBasicTelephony.fireCallEvent(AbstractOperationSetBasicTelephony.java:112)
  at net.java.sip.communicator.impl.protocol.sip.CallSipImpl.createCallPeerFor(CallSipImpl.java:336)
  at net.java.sip.communicator.impl.protocol.sip.CallSipImpl.processInvite(CallSipImpl.java:423)
  at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processInvite(OperationSetBasicTelephonySipImpl.java:1075)
  at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.processRequest(OperationSetBasicTelephonySipImpl.java:364)
  at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.processRequest(ProtocolProviderServiceSipImpl.java:904)
  at net.java.sip.communicator.impl.protocol.sip.SipStackSharing.processRequest(SipStackSharing.java:646)
  at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:230)
  at gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:196)
  at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:1303)
  at gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:847)
  at gov.nist.javax.sip.stack.UDPMessageChannel.processMessage(UDPMessageChannel.java:540)
  at gov.nist.javax.sip.stack.UDPMessageChannel.processIncomingDataPacket(UDPMessageChannel.java:492)
  at gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:297)
  at java.lang.Thread.run(Unknown Source)

I'm sure you can improve this even though the patchset itself is already enough to get the new feature going (for anyone interested).

Any thoughts?

Thanks,

Vieri


#7

I updated http://java.net/jira/browse/JITSI-1034 so that Jitsi can also notify the callee of the rejected calls (popup message, short sound and call history).

Any suggestions on how to improve it?

Thanks,

Vieri

···

--- On Wed, 7/4/12, Vieri <rentorbuy@yahoo.com> wrote:

I posted some patches on JIRA:

http://java.net/jira/browse/JITSI-1034