[sip-comm-dev] DTMF Junit test


#1

Hello

Today I was thinking about JUnit tests.

The DTMF project can be splitted into multiple pieces:
  - Configuration_GUI : add a Checkbox in the SIP wizard.
  - Dial_Panel_GUI : when the user press and release digits it calls the
function startSendingDtmf(digit) and stopSendingDtmf()
  - OperationSetDTMF dispatcher : the functions startSendingDtmf(digit) and
stopSendingDtmf() are dispatched to DtmfRtpHandler or DtmfSipInfoHandler
class depending on the configuration made in the SIP wizard.
  - SDP negociation : When phones send SIP INVITE packet, they join an SDP
description. If, in the SDP description we saw that both the remote side and
our side accept DTMF, we save the DTMF payload type of the SDP offerer to
use it later in the DTMF protocol.
  - DTMF transformation : Use the JMF RTPConnector to get full control of
the Socket and transform outcoming packets.

But doing JUnit tests is quite difficult for some parts.
  - the GUI tests : I looked into the test package but found no exemples of
tests on the GUI. Is the GUI testable? Do we want tests on this?
  - OperationSetDTMF dispatcher : We just need to change the configuration
value and check that the dispatching is correct. It looks easy.
  - SDP negociation : To test it we need to generate different SDP
descriptions and add them in the Call process (because the SDP negiciation
happens in CallSessionImpl). Emil I know that you will change this class
soon. Do you want me to add tests on it?
  - DTMF transformation : Because we get the control of the Socket, we can
not do transformation with 2 phones on the same computer. So I don't think
we can test the transform part (Add connector, add engine, ...)
But we could still test the function : public RawPacket transform(RawPacket
pkt) of DtmfRtpPacketTransformer class because it just changes one RawPacket
into an other one.
In order to test the whole DTMF protocol, we will need to call the functions
public void startSendingDtmf(int digit) and public void stopSendingDtmf() of
DtmfTransformEngine.

I think that in DTMF there is three things to test :
  - the structure of the packet should match the RFC :
        0 1 2 3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

···

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        >V=2|P|X| CC |M| PT | sequence number |
        > 2 |0|0| 0 |0| 100 | 18 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        > timestamp |
        > 11200 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        > synchronization source (SSRC) identifier |
        > 0x5234a8 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        > event |E R| volume | duration |
        > 1 |1 0| 0 | 1760 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

  - the protocol :
    * we first send a packet with the RTP marker set
    * then we send updates packets
    * to conclude we send 3 last packets with the duration freezed (2 with
the End flag set).
    * the seqnum is not modified by the transformation
    * the timestamp is freezed
    * the duration increase

  - the extra functions of our implementation
    * timeout occurs after 8s
    * it is impossible to lost packets by calling stopSendingDtmf() just
after startSendingDtmf(digit)

This is all I found about testings in DTMF.

Cheers

Romain


#2

Hey Romain,

Romain wrote:

Hello

Today I was thinking about JUnit tests.

The DTMF project can be splitted into multiple pieces:
  - Configuration_GUI : add a Checkbox in the SIP wizard.
  - Dial_Panel_GUI : when the user press and release digits it calls the
function startSendingDtmf(digit) and stopSendingDtmf()
  - OperationSetDTMF dispatcher : the functions startSendingDtmf(digit)
and stopSendingDtmf() are dispatched to DtmfRtpHandler or
DtmfSipInfoHandler class depending on the configuration made in the SIP
wizard.
  - SDP negociation : When phones send SIP INVITE packet, they join an
SDP description. If, in the SDP description we saw that both the remote
side and our side accept DTMF, we save the DTMF payload type of the SDP
offerer to use it later in the DTMF protocol.
  - DTMF transformation : Use the JMF RTPConnector to get full control
of the Socket and transform outcoming packets.

But doing JUnit tests is quite difficult for some parts.
  - the GUI tests : I looked into the test package but found no exemples
of tests on the GUI. Is the GUI testable? Do we want tests on this?

We don't have tests for any other parts of the GUI as we haven't
discovered an UI testing framework that would allows us to do unit
testing for SC's user interface in a way that would make sense.

  - OperationSetDTMF dispatcher : We just need to change the
configuration value and check that the dispatching is correct. It looks
easy.
  - SDP negociation : To test it we need to generate different SDP
descriptions and add them in the Call process (because the SDP
negiciation happens in CallSessionImpl). Emil I know that you will
change this class soon. Do you want me to add tests on it?
  - DTMF transformation : Because we get the control of the Socket, we
can not do transformation with 2 phones on the same computer. So I don't
think we can test the transform part (Add connector, add engine, ...)
But we could still test the function : public RawPacket
transform(RawPacket pkt) of DtmfRtpPacketTransformer class because it
just changes one RawPacket into an other one.
In order to test the whole DTMF protocol, we will need to call the
functions public void startSendingDtmf(int digit) and public void
stopSendingDtmf() of DtmfTransformEngine.

I think that in DTMF there is three things to test :
  - the structure of the packet should match the RFC :
        0 1 2 3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        >V=2|P|X| CC |M| PT | sequence number |
        > 2 |0|0| 0 |0| 100 | 18 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        > timestamp |
        > 11200 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        > synchronization source (SSRC) identifier |
        > 0x5234a8 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        > event |E R| volume | duration |
        > 1 |1 0| 0 | 1760 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       
  - the protocol :
    * we first send a packet with the RTP marker set
    * then we send updates packets
    * to conclude we send 3 last packets with the duration freezed (2
with the End flag set).
    * the seqnum is not modified by the transformation
    * the timestamp is freezed
    * the duration increase

  - the extra functions of our implementation
    * timeout occurs after 8s
    * it is impossible to lost packets by calling stopSendingDtmf() just
after startSendingDtmf(digit)

Actually, the best way to handle DTMF testing the SC way would be to do
it as a part of the protocol provider slick. The tests could send DTMFs
from one side and make sure they were properly received at the other
side. In order to make this possible however we'd also have to implement
support for receiving DTMF. Given all the experience you now have with
the media package this should be relatively straightforward to you.
Still, it represents a considerable amount of work and may take all your
time until the end of the GSoC season. However, even if this turns out
to be the case it would still be worth it since it would pave the way
for whoeverer decides to take up on this task later on and it would also
allow SC plugins to handle incoming DTMF events if they ever need to.

What do you think?
Emil

···

This is all I found about testings in DTMF.

Cheers

Romain

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


#3

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

                {

                    Logger.info("start:"time());

                    telephony.hangupCallParticipant(participant);

                    Logger.info("end:"time());

                }

            catch (OperationFailedException e){

            ...

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

···

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


#4

After some debugging it turns out that

In class
  MediaControl.java

In function

  public void stopProcessingMedia(Object reader)

the call to
  avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

···

-----Original Message-----

From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]

Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

                {

                    Logger.info("start:"time());

                    telephony.hangupCallParticipant(participant);

                    Logger.info("end:"time());

                }

            catch (OperationFailedException e){

            ...

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#5

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

···

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
MediaControl.java

In function

   public void stopProcessingMedia\(Object reader\)

the call to
avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

           \{

               Logger\.info\(&quot;start:&quot;time\(\)\);

               telephony\.hangupCallParticipant\(participant\);

               Logger\.info\(&quot;end:&quot;time\(\)\);

           \}

       catch \(OperationFailedException e\)\{

       \.\.\.

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#6

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

···

-----Original Message-----

From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]

Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
MediaControl.java

In function

   public void stopProcessingMedia\(Object reader\)

the call to
avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

           \{

               Logger\.info\(&quot;start:&quot;time\(\)\);

               telephony\.hangupCallParticipant\(participant\);

               Logger\.info\(&quot;end:&quot;time\(\)\);

           \}

       catch \(OperationFailedException e\)\{

       \.\.\.

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#7

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.

···

On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
MediaControl.java

In function

   public void stopProcessingMedia\(Object reader\)

the call to
avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

           \{

               Logger\.info\(&quot;start:&quot;time\(\)\);

               telephony\.hangupCallParticipant\(participant\);

               Logger\.info\(&quot;end:&quot;time\(\)\);

           \}

       catch \(OperationFailedException e\)\{

       \.\.\.

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#8

Lubo, Carlos,

see my emails to the list dated December 7, 2008 at 12:18 and 15:09.
SC thread was blocked at dataSource.disconnect(). I did an update
to Java 1.6 and the problem didn't show up (running openSuse 10.3
at that time). However, sometimes I figure a strange delay when hanging
up even today, not full reproducible at my system here. I need to
check if we entered an issue in the issue tracker.

Regards,
Werner

back in December I had the same problem

Lubomir Marinov schrieb:

···

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.
12:18 and 15:09
On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
       MediaControl.java

In function

       public void stopProcessingMedia(Object reader)

the call to
       avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: ter�a-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

               {

                   Logger.info("start:"time());

                   telephony.hangupCallParticipant(participant);

                   Logger.info("end:"time());

               }

           catch (OperationFailedException e){

           ...

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#9

Hi Werner
Im experiencing this problem with java 1.6

Thanks
Carlos

···

-----Original Message-----

From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]

Sent: quinta-feira, 6 de Agosto de 2009 20:04
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Lubo, Carlos,

see my emails to the list dated December 7, 2008 at 12:18 and 15:09.
SC thread was blocked at dataSource.disconnect(). I did an update
to Java 1.6 and the problem didn't show up (running openSuse 10.3
at that time). However, sometimes I figure a strange delay when hanging
up even today, not full reproducible at my system here. I need to
check if we entered an issue in the issue tracker.

Regards,
Werner

back in December I had the same problem

Lubomir Marinov schrieb:

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.
12:18 and 15:09
On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
       MediaControl.java

In function

       public void stopProcessingMedia(Object reader)

the call to
       avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

               {

                   Logger.info("start:"time());

                   telephony.hangupCallParticipant(participant);

                   Logger.info("end:"time());

               }

           catch (OperationFailedException e){

           ...

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#10

Dieter

I looked up your messages from December 7, 2008 at 12:18 and 15:09.

Did you solve this problem just by upgrading to java 1.6 ?

Did you use FMJ like someone suggested you then ?

Im amazed that theres no one else with this problem....

Thanks for your help

Carlos

···

-----Original Message-----

From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]

Sent: quinta-feira, 6 de Agosto de 2009 20:04
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Lubo, Carlos,

see my emails to the list dated December 7, 2008 at 12:18 and 15:09.
SC thread was blocked at dataSource.disconnect(). I did an update
to Java 1.6 and the problem didn't show up (running openSuse 10.3
at that time). However, sometimes I figure a strange delay when hanging
up even today, not full reproducible at my system here. I need to
check if we entered an issue in the issue tracker.

Regards,
Werner

back in December I had the same problem

Lubomir Marinov schrieb:

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.
12:18 and 15:09
On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
       MediaControl.java

In function

       public void stopProcessingMedia(Object reader)

the call to
       avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

               {

                   Logger.info("start:"time());

                   telephony.hangupCallParticipant(participant);

                   Logger.info("end:"time());

               }

           catch (OperationFailedException e){

           ...

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#11

Hello

Has anyone been using FMJ instead of JMF?
Im having problems with JMF ( the dataSource.disconnect() issue), and though to give a try with FMJ.

Im using Debian as a S.O.

Hás anyone tryed this solution?
Any positive feedback?
Are distributions of SC allready with FMJ?

Thanks

Carlos

···

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


#12

Dieter

I looked up your messages from December 7, 2008 at 12:18 and 15:09.

Did you solve this problem just by upgrading to java 1.6 ?

Did you use FMJ like someone suggested you then ?

Im amazed that theres no one else with this problem....

Thanks for your help

Carlos

···

-----Original Message-----

From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]

Sent: sexta-feira, 7 de Agosto de 2009 15:00
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Hi Werner
Im experiencing this problem with java 1.6

Thanks
Carlos

-----Original Message-----

From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]

Sent: quinta-feira, 6 de Agosto de 2009 20:04
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Lubo, Carlos,

see my emails to the list dated December 7, 2008 at 12:18 and 15:09.
SC thread was blocked at dataSource.disconnect(). I did an update
to Java 1.6 and the problem didn't show up (running openSuse 10.3
at that time). However, sometimes I figure a strange delay when hanging
up even today, not full reproducible at my system here. I need to
check if we entered an issue in the issue tracker.

Regards,
Werner

back in December I had the same problem

Lubomir Marinov schrieb:

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.
12:18 and 15:09
On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
       MediaControl.java

In function

       public void stopProcessingMedia(Object reader)

the call to
       avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

               {

                   Logger.info("start:"time());

                   telephony.hangupCallParticipant(participant);

                   Logger.info("end:"time());

               }

           catch (OperationFailedException e){

           ...

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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

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


#13

Hi guys , Lubo, Werner.

As you remember i was complaining about the hanging up of calls taking a lot of time in Debian. The hanging up was taking up to 20 seconds+ to disconnect ( sometimes it even blocked).

This was the same that Werner was complaining about too.

Well, I followed Lubo´s sugestion ("look into the exact class and method being called by" ).

So, at net.java.sip.communicator.impl.media.MutePushBufferDataSource.java, I did a very simple change in the code that solved completely my problem.

I wrote down below the original function, and also my altered version.

I just changed "public void disconnect()" at net.java.sip.communicator.impl.media.MutePushBufferDataSource.java

See if this makes sense to you, and if it is possible to commit it or not. Or if you can suggest a better solution.

Thanks

/*ORIGINAL CODE */
    /*
     * Implements DataSource#disconnect(). Delegates to the wrapped
     * PushBufferDataSource.
     */

    public void disconnect()
    {
        dataSource.disconnect();
    }

/* CHANGED CODE */

    /*
     * Implements DataSource#disconnect(). Delegates to the wrapped
     * PushBufferDataSource.
     */
    public void disconnect()
    {
        try{
            dataSource.stop();
        }catch(Exception e){
            System.out.println(e);
        }
        dataSource.disconnect();
    }

···

-----Original Message-----

From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]

Sent: terça-feira, 18 de Agosto de 2009 15:03
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Dieter

I looked up your messages from December 7, 2008 at 12:18 and 15:09.

Did you solve this problem just by upgrading to java 1.6 ?

Did you use FMJ like someone suggested you then ?

Im amazed that theres no one else with this problem....

Thanks for your help

Carlos

-----Original Message-----

From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]

Sent: sexta-feira, 7 de Agosto de 2009 15:00
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Hi Werner
Im experiencing this problem with java 1.6

Thanks
Carlos

-----Original Message-----

From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]

Sent: quinta-feira, 6 de Agosto de 2009 20:04
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Lubo, Carlos,

see my emails to the list dated December 7, 2008 at 12:18 and 15:09.
SC thread was blocked at dataSource.disconnect(). I did an update
to Java 1.6 and the problem didn't show up (running openSuse 10.3
at that time). However, sometimes I figure a strange delay when hanging
up even today, not full reproducible at my system here. I need to
check if we entered an issue in the issue tracker.

Regards,
Werner

back in December I had the same problem

Lubomir Marinov schrieb:

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.
12:18 and 15:09
On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
       MediaControl.java

In function

       public void stopProcessingMedia(Object reader)

the call to
       avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

               {

                   Logger.info("start:"time());

                   telephony.hangupCallParticipant(participant);

                   Logger.info("end:"time());

               }

           catch (OperationFailedException e){

           ...

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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

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


#14

Carlos,

could make sense if the DataSource#disconnect() was/is not implemented
correctly. According to the documentation of JMF DataSoure#disconnect():

<quote>
Close the connection to the source described by the locator.

The disconnect method frees resources used to maintain a connection
to the source. If no resources are in use, disconnect is ignored. If
stop hasn't already been called, calling disconnect implies a stop.
</quote>

Thus calling stop before disconnect does not do any harm in any case but
it may solve problems in case of incorrect implementations of a DataSource
class. DataSource and PushBufferDataSource are abstract classes and the
real implemetation of the calsses must implement disconnect()( and stop().
Thus cahnces are good that a implementation of disconnect() may be
incorrect.

Regards,
Werner

Carlos Alexandre schrieb:

···

Hi guys , Lubo, Werner.

As you remember i was complaining about the hanging up of calls taking a lot of time in Debian. The hanging up was taking up to 20 seconds+ to disconnect ( sometimes it even blocked).

This was the same that Werner was complaining about too.

Well, I followed Lubo�s sugestion ("look into the exact class and method being called by" ).

So, at net.java.sip.communicator.impl.media.MutePushBufferDataSource.java, I did a very simple change in the code that solved completely my problem.

I wrote down below the original function, and also my altered version.

I just changed "public void disconnect()" at net.java.sip.communicator.impl.media.MutePushBufferDataSource.java

See if this makes sense to you, and if it is possible to commit it or not. Or if you can suggest a better solution.

Thanks

/*ORIGINAL CODE */
    /*
     * Implements DataSource#disconnect(). Delegates to the wrapped
     * PushBufferDataSource.
     */

    public void disconnect()
    {
        dataSource.disconnect();
    }

/* CHANGED CODE */

    /*
     * Implements DataSource#disconnect(). Delegates to the wrapped
     * PushBufferDataSource.
     */
    public void disconnect()
    {
        try{
            dataSource.stop();
        }catch(Exception e){
            System.out.println(e);
        }
        dataSource.disconnect();
    }

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: ter�a-feira, 18 de Agosto de 2009 15:03
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Dieter

I looked up your messages from December 7, 2008 at 12:18 and 15:09.

Did you solve this problem just by upgrading to java 1.6 ?

Did you use FMJ like someone suggested you then ?

Im amazed that theres no one else with this problem....

Thanks for your help

Carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: sexta-feira, 7 de Agosto de 2009 15:00
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Hi Werner
Im experiencing this problem with java 1.6

Thanks
Carlos

-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
Sent: quinta-feira, 6 de Agosto de 2009 20:04
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Lubo, Carlos,

see my emails to the list dated December 7, 2008 at 12:18 and 15:09.
SC thread was blocked at dataSource.disconnect(). I did an update
to Java 1.6 and the problem didn't show up (running openSuse 10.3
at that time). However, sometimes I figure a strange delay when hanging
up even today, not full reproducible at my system here. I need to
check if we entered an issue in the issue tracker.

Regards,
Werner

back in December I had the same problem

Lubomir Marinov schrieb:

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.
12:18 and 15:09
On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
       MediaControl.java

In function

       public void stopProcessingMedia(Object reader)

the call to
       avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: ter�a-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

               {

                   Logger.info("start:"time());

                   telephony.hangupCallParticipant(participant);

                   Logger.info("end:"time());

               }

           catch (OperationFailedException e){

           ...

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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

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


#15

Hi Carlos,

Thank you for working on this issue to it successful resolution!

I applied your idea but I modified it very slightly for technical
reasons and I stopped the avDataSource before disconnecting it instead
of stopping in the MutePushBufferDataSource. I did it because
MutePushBufferDataSource is supposed to wrap another DataSource so it
delegates the respective calls to the wrapped DataSource as strictly
as possible, it's not meant to fix bugs in the DataSource. Besides, if
one DataSource implementation requires calling stop() before
disconnect() in order to work faster, then we don't know whether
another implementation doesn't need it as well and it seems safer to
just do it in the general case. My debugging shows me that the order
of stop() and disconnect() is now as you specified in your fix.

Could you please test r5840 and let us know if it works for you?

Best regards,
Lubomir

···

On Thu, Aug 20, 2009 at 4:53 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi guys , Lubo, Werner.

As you remember i was complaining about the hanging up of calls taking a lot of time in Debian. The hanging up was taking up to 20 seconds+ to disconnect ( sometimes it even blocked).

This was the same that Werner was complaining about too.

Well, I followed Lubo´s sugestion ("look into the exact class and method being called by" ).

So, at net.java.sip.communicator.impl.media.MutePushBufferDataSource.java, I did a very simple change in the code that solved completely my problem.

I wrote down below the original function, and also my altered version.

I just changed "public void disconnect()" at net.java.sip.communicator.impl.media.MutePushBufferDataSource.java

See if this makes sense to you, and if it is possible to commit it or not. Or if you can suggest a better solution.

Thanks

/*ORIGINAL CODE */
/*
* Implements DataSource#disconnect(). Delegates to the wrapped
* PushBufferDataSource.
*/

public void disconnect()
{
dataSource.disconnect();
}

/* CHANGED CODE */

/*
* Implements DataSource#disconnect(). Delegates to the wrapped
* PushBufferDataSource.
*/
public void disconnect()
{
try{
dataSource.stop();
}catch(Exception e){
System.out.println(e);
}
dataSource.disconnect();
}

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 18 de Agosto de 2009 15:03
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Dieter

I looked up your messages from December 7, 2008 at 12:18 and 15:09.

Did you solve this problem just by upgrading to java 1.6 ?

Did you use FMJ like someone suggested you then ?

Im amazed that theres no one else with this problem....

Thanks for your help

Carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: sexta-feira, 7 de Agosto de 2009 15:00
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Hi Werner
Im experiencing this problem with java 1.6

Thanks
Carlos

-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
Sent: quinta-feira, 6 de Agosto de 2009 20:04
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Lubo, Carlos,

see my emails to the list dated December 7, 2008 at 12:18 and 15:09.
SC thread was blocked at dataSource.disconnect(). I did an update
to Java 1.6 and the problem didn't show up (running openSuse 10.3
at that time). However, sometimes I figure a strange delay when hanging
up even today, not full reproducible at my system here. I need to
check if we entered an issue in the issue tracker.

Regards,
Werner

back in December I had the same problem

Lubomir Marinov schrieb:

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.
12:18 and 15:09
On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
MediaControl.java

In function

   public void stopProcessingMedia\(Object reader\)

the call to
avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

           \{

               Logger\.info\(&quot;start:&quot;time\(\)\);

               telephony\.hangupCallParticipant\(participant\);

               Logger\.info\(&quot;end:&quot;time\(\)\);

           \}

       catch \(OperationFailedException e\)\{

       \.\.\.

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#16

Hi guys

Thanks for the changes.

I know that the API of JMF says that the disconnect() implies a stop(), but calling a stop() explicitly really makes a difference :slight_smile:

Which nightly build is r5840?
For future purposes, How can i map between revisions and nightly builds ?

Thanks

Carlos

···

-----Original Message-----

From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]

Sent: quinta-feira, 20 de Agosto de 2009 19:31
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay hanging up SIP Calls : SOLVED !!!

Hi Carlos,

Thank you for working on this issue to it successful resolution!

I applied your idea but I modified it very slightly for technical
reasons and I stopped the avDataSource before disconnecting it instead
of stopping in the MutePushBufferDataSource. I did it because
MutePushBufferDataSource is supposed to wrap another DataSource so it
delegates the respective calls to the wrapped DataSource as strictly
as possible, it's not meant to fix bugs in the DataSource. Besides, if
one DataSource implementation requires calling stop() before
disconnect() in order to work faster, then we don't know whether
another implementation doesn't need it as well and it seems safer to
just do it in the general case. My debugging shows me that the order
of stop() and disconnect() is now as you specified in your fix.

Could you please test r5840 and let us know if it works for you?

Best regards,
Lubomir

On Thu, Aug 20, 2009 at 4:53 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi guys , Lubo, Werner.

As you remember i was complaining about the hanging up of calls taking a lot of time in Debian. The hanging up was taking up to 20 seconds+ to disconnect ( sometimes it even blocked).

This was the same that Werner was complaining about too.

Well, I followed Lubo´s sugestion ("look into the exact class and method being called by" ).

So, at net.java.sip.communicator.impl.media.MutePushBufferDataSource.java, I did a very simple change in the code that solved completely my problem.

I wrote down below the original function, and also my altered version.

I just changed "public void disconnect()" at net.java.sip.communicator.impl.media.MutePushBufferDataSource.java

See if this makes sense to you, and if it is possible to commit it or not. Or if you can suggest a better solution.

Thanks

/*ORIGINAL CODE */
/*
* Implements DataSource#disconnect(). Delegates to the wrapped
* PushBufferDataSource.
*/

public void disconnect()
{
dataSource.disconnect();
}

/* CHANGED CODE */

/*
* Implements DataSource#disconnect(). Delegates to the wrapped
* PushBufferDataSource.
*/
public void disconnect()
{
try{
dataSource.stop();
}catch(Exception e){
System.out.println(e);
}
dataSource.disconnect();
}

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 18 de Agosto de 2009 15:03
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Dieter

I looked up your messages from December 7, 2008 at 12:18 and 15:09.

Did you solve this problem just by upgrading to java 1.6 ?

Did you use FMJ like someone suggested you then ?

Im amazed that theres no one else with this problem....

Thanks for your help

Carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: sexta-feira, 7 de Agosto de 2009 15:00
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Hi Werner
Im experiencing this problem with java 1.6

Thanks
Carlos

-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
Sent: quinta-feira, 6 de Agosto de 2009 20:04
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

Lubo, Carlos,

see my emails to the list dated December 7, 2008 at 12:18 and 15:09.
SC thread was blocked at dataSource.disconnect(). I did an update
to Java 1.6 and the problem didn't show up (running openSuse 10.3
at that time). However, sometimes I figure a strange delay when hanging
up even today, not full reproducible at my system here. I need to
check if we entered an issue in the issue tracker.

Regards,
Werner

back in December I had the same problem

Lubomir Marinov schrieb:

I'm on Ubuntu and I'm not seeing such a delay.

Line 971 : avDataSource.disconnect();

Avdatasource is a javax.media.protocol.DataSource object.

javax.media.protocol.DataSource#disconnect() is an abstract method so
it couldn't possibly be the cause of the delay. avDataSource can be
the audio capture device, the video capture device or both. Which
means that the delay is being caused by an implementation of
javax.media.protocol.DataSource#disconnect(). That's why I suggested
that you look into the exact class and method being called by
avDataSource#disconnect() which causes the delay.

It may also help to know whether another application which uses your
capture devices experiences the same delay. For example, if the delay
turns out to be in JavaSound code, it may be worth looking into the
delay in other applications which employ JavaSound for similar
purposes.
12:18 and 15:09
On Thu, Aug 6, 2009 at 2:24 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

Hi Lubomir
Im not shure i understood you.

I have allready narrowed down the cause of the delay:

net.java.sip.communicator.impl.media.MediaControl,

Line 971 : avDataSource.disconnect();

Is this not happening to anyone else ?

-----Original Message-----
From: Lubomir Marinov [mailto:lubomir.marinov@gmail.com]
Sent: quarta-feira, 5 de Agosto de 2009 19:37
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strong delay answering or placing consecutive sip calls

I don't have an answer to your question.

But since avDataSource can be a merging DataSource, it may be worth
looking into the avDataSource#disconnect() callees and pinpointing the
one which causes the delay. A profiler, for example, will be able to
trace (or sample, for that matter, given the long delay) the very
class and method which causes the delay.

On Wed, Aug 5, 2009 at 8:50 PM, Carlos Alexandre<Carlos.Alexandre@nav.pt> wrote:

After some debugging it turns out that

In class
MediaControl.java

In function

   public void stopProcessingMedia\(Object reader\)

the call to
avDatasource.disconnect();

Is responsible for the delay.

Avdatasource is a javax.media.protocol.DataSource object.

As i said, this delay, in Debian, sometimes takes over 20 seconds, forcing a waiting time between answering or making two consecutive calls.

Any idea how to eliminate this delay?

Thanks

carlos

-----Original Message-----
From: Carlos Alexandre [mailto:Carlos.Alexandre@nav.pt]
Sent: terça-feira, 4 de Agosto de 2009 14:18
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strong delay answering consecutive sip calls

Hello to all

Im facing a new problem with my sip calls.

This only happens on Debian, it hasnt happened on Windows so far. Im
using build 1941

It goes like this.

When a call is Hang up, it takes many seconds ( sometimes up to 30 secs)
to really finish the call.

This is perceptible if:

-you have two incoming calls ringing at SC,

-you answer the first call

-you hung up the first call

-You answer the second call

-nothing happens for a few seconds

- the second call is finally connected after some seconds

I did some logging in the code and came up with this:

The delay is related with:

impl.gui.main.call.CallManager , at HangupCallThread.run:

...

try

           \{

               Logger\.info\(&quot;start:&quot;time\(\)\);

               telephony\.hangupCallParticipant\(participant\);

               Logger\.info\(&quot;end:&quot;time\(\)\);

           \}

       catch \(OperationFailedException e\)\{

       \.\.\.

Between start and end, sometimes it takes up to 30 secs. And the second
call doesnt get connected while this action doesnt finish.

Does this happens to you too?

Thanks

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


#17

Hey Carlos,

Carlos Alexandre wrote:

Which nightly build is r5840?

Seems to be 1992.

For future purposes, How can i map between revisions and nightly
builds ?

You can subscribe to the cruisecontrol mailing list in order to get
mails from the build process. Every build mail corresponds to a specific
build and the body lists the specific SVN revision numbers that the new
build integrates.

Hope this helps,

Emil

···

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