[sip-comm-dev] Strange message during shutdown - SIP stack


#1

During some tests I experience a strange behaviour when calling another
SC. The first call works, the second doesn't. Sometimes I see the following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit instead
of graceful.

Does somebody has more insight to this?

Regards,
Werner

Console printout:

     [java] ERROR: Error stopping reference:file:sc-bundles/protocol-sip.jar (org.osgi.framework.BundleException: Activator stop error in bundle [13].)

     [java] java.lang.NullPointerException
     [java] at gov.nist.javax.sip.stack.SIPClientTransaction.startTransactionTimer(SIPClientTransaction.java:1322)

     [java] at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:741)

     [java] at gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:486)

     [java] at gov.nist.javax.sip.stack.SIPClientTransaction.sendRequest(SIPClientTransaction.java:986)

     [java] at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregister(SipRegistrarConnection.java:675)

     [java] at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregister(SipRegistrarConnection.java:556)

     [java] at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.unregister(ProtocolProviderServiceSipImpl.java:339)
     [java] at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl$ShutdownThread.run(ProtocolProviderServiceSipImpl.java:826)
     [java] at java.lang.Thread.run(Thread.java:619)
     [java] at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.shutdown(ProtocolProviderServiceSipImpl.java:801)
     [java] at net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(ProtocolProviderFactory.java:788)
     [java] at net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(ProtocolProviderFactory.java:765)
     [java] at net.java.sip.communicator.impl.protocol.sip.SipActivator.stop(SipActivator.java:213)
     [java] at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:611)
     [java] at org.apache.felix.framework.Felix._stopBundle(Felix.java:2047)
     [java] at org.apache.felix.framework.Felix.stopBundle(Felix.java:2004)
     [java] at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1188)
     [java] at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
     [java] at java.lang.Thread.run(Thread.java:619)

BUILD SUCCESSFUL
Total time: 2 minutes 59 seconds

···

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


#2

This seems related to the bug submitted here:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=467

I have been facing similar problems. I tested this on OS X, XP and Ubuntu. Problem was easily reproduced on all platforms.

-- Akshat

···

On Dec 27, 2008, at 8:32 AM, Werner Dittmann wrote:

During some tests I experience a strange behaviour when calling another
SC. The first call works, the second doesn't. Sometimes I see the following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit instead
of graceful.

Does somebody has more insight to this?

Regards,
Werner

Console printout:

     [java] ERROR: Error stopping reference:file:sc-bundles/protocol-sip.jar (org.osgi.framework.BundleException: Activator stop error in bundle [13].)

     [java] java.lang.NullPointerException
     [java] at gov.nist.javax.sip.stack.SIPClientTransaction.startTransactionTimer(SIPClientTransaction.java:1322)

     [java] at gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:741)

     [java] at gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:486)

     [java] at gov.nist.javax.sip.stack.SIPClientTransaction.sendRequest(SIPClientTransaction.java:986)

     [java] at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregister(SipRegistrarConnection.java:675)

     [java] at net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregister(SipRegistrarConnection.java:556)

     [java] at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.unregister(ProtocolProviderServiceSipImpl.java:339)
     [java] at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl$ShutdownThread.run(ProtocolProviderServiceSipImpl.java:826)
     [java] at java.lang.Thread.run(Thread.java:619)
     [java] at net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.shutdown(ProtocolProviderServiceSipImpl.java:801)
     [java] at net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(ProtocolProviderFactory.java:788)
     [java] at net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(ProtocolProviderFactory.java:765)
     [java] at net.java.sip.communicator.impl.protocol.sip.SipActivator.stop(SipActivator.java:213)
     [java] at org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:611)
     [java] at org.apache.felix.framework.Felix._stopBundle(Felix.java:2047)
     [java] at org.apache.felix.framework.Felix.stopBundle(Felix.java:2004)
     [java] at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1188)
     [java] at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
     [java] at java.lang.Thread.run(Thread.java:619)

BUILD SUCCESSFUL
Total time: 2 minutes 59 seconds

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


#3

I've been seeing the same thing, or something similar, for a while now. You
can only make one outgoing call before SC freezes up, and when I look at the
logs, there's an NPE (I don't have the logs with me so I can't check to see
if it's the same one you're seeing). My guess from my previous
investigations would be that the single sip stack changes have a bug in them
which doesnt properly recycle the sip stack. I didn't have time before the
holidays to send out the error messages yet, and I won't have access to them
again until at least Monday.

···

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

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

Sent: Saturday, December 27, 2008 8:33 AM
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strange message during shutdown - SIP stack

During some tests I experience a strange behaviour when calling another SC.
The first call works, the second doesn't. Sometimes I see the following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit instead of
graceful.

Does somebody has more insight to this?

Regards,
Werner

Console printout:

     [java] ERROR: Error stopping reference:file:sc-bundles/protocol-sip.jar
(org.osgi.framework.BundleException: Activator stop error in bundle [13].)

     [java] java.lang.NullPointerException
     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.startTransactionTimer(SIPClien
tTransaction.java:1322)

     [java] at
gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:741)

     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransacti
on.java:486)

     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.sendRequest(SIPClientTransacti
on.java:986)

     [java] at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregiste
r(SipRegistrarConnection.java:675)

     [java] at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregiste
r(SipRegistrarConnection.java:556)

     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.u
nregister(ProtocolProviderServiceSipImpl.java:339)
     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl$S
hutdownThread.run(ProtocolProviderServiceSipImpl.java:826)
     [java] at java.lang.Thread.run(Thread.java:619)
     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.s
hutdown(ProtocolProviderServiceSipImpl.java:801)
     [java] at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(Prot
ocolProviderFactory.java:788)
     [java] at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(Prot
ocolProviderFactory.java:765)
     [java] at
net.java.sip.communicator.impl.protocol.sip.SipActivator.stop(SipActivator.j
ava:213)
     [java] at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java
:611)
     [java] at
org.apache.felix.framework.Felix._stopBundle(Felix.java:2047)
     [java] at
org.apache.felix.framework.Felix.stopBundle(Felix.java:2004)
     [java] at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1188)
     [java] at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
     [java] at java.lang.Thread.run(Thread.java:619)

BUILD SUCCESSFUL
Total time: 2 minutes 59 seconds

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


#4

Akshat,

thanks for the pointer. I need to check the bugzilla more often :slight_smile: .

Just as an additional information: I see this behaviour only if the
calls are between two SC (both parties use a SC). If I call other
SIP clients (in my normal test scenario I use a _very_ old implementation
of minisip) this doesn't happen. At least I don't experience the
blocking of SC as the bug report describes.

Because I rarely use a SC to SC scenario I never saw this behaviour
before.

Regards,
Werner

Akshat Sikarwar schrieb:

···

This seems related to the bug submitted here:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=467

I have been facing similar problems. I tested this on OS X, XP and
Ubuntu. Problem was easily reproduced on all platforms.

-- Akshat

On Dec 27, 2008, at 8:32 AM, Werner Dittmann wrote:

During some tests I experience a strange behaviour when calling another
SC. The first call works, the second doesn't. Sometimes I see the
following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit instead
of graceful.

Does somebody has more insight to this?

Regards,
Werner

Console printout:

     [java] ERROR: Error stopping
reference:file:sc-bundles/protocol-sip.jar
(org.osgi.framework.BundleException: Activator stop error in bundle
[13].)

     [java] java.lang.NullPointerException
     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.startTransactionTimer(SIPClientTransaction.java:1322)

     [java] at
gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:741)

     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransaction.java:486)

     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.sendRequest(SIPClientTransaction.java:986)

     [java] at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregister(SipRegistrarConnection.java:675)

     [java] at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregister(SipRegistrarConnection.java:556)

     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.unregister(ProtocolProviderServiceSipImpl.java:339)

     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl$ShutdownThread.run(ProtocolProviderServiceSipImpl.java:826)

     [java] at java.lang.Thread.run(Thread.java:619)
     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.shutdown(ProtocolProviderServiceSipImpl.java:801)

     [java] at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(ProtocolProviderFactory.java:788)

     [java] at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(ProtocolProviderFactory.java:765)

     [java] at
net.java.sip.communicator.impl.protocol.sip.SipActivator.stop(SipActivator.java:213)

     [java] at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java:611)

     [java] at
org.apache.felix.framework.Felix._stopBundle(Felix.java:2047)
     [java] at
org.apache.felix.framework.Felix.stopBundle(Felix.java:2004)
     [java] at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1188)
     [java] at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
     [java] at java.lang.Thread.run(Thread.java:619)

BUILD SUCCESSFUL
Total time: 2 minutes 59 seconds

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


#5

Alan,

I don't think this problem was introduced with the single SIP stack patch.

The bugzilla entry dates from Oct 22 but the single SIP stack patch was
merged end of November IIRC .

Regards,
Werner

Alan Kelly schrieb:

···

I've been seeing the same thing, or something similar, for a while now. You
can only make one outgoing call before SC freezes up, and when I look at the
logs, there's an NPE (I don't have the logs with me so I can't check to see
if it's the same one you're seeing). My guess from my previous
investigations would be that the single sip stack changes have a bug in them
which doesnt properly recycle the sip stack. I didn't have time before the
holidays to send out the error messages yet, and I won't have access to them
again until at least Monday.

-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
Sent: Saturday, December 27, 2008 8:33 AM
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Strange message during shutdown - SIP stack

During some tests I experience a strange behaviour when calling another SC.
The first call works, the second doesn't. Sometimes I see the following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit instead of
graceful.

Does somebody has more insight to this?

Regards,
Werner

Console printout:

     [java] ERROR: Error stopping reference:file:sc-bundles/protocol-sip.jar
(org.osgi.framework.BundleException: Activator stop error in bundle [13].)

     [java] java.lang.NullPointerException
     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.startTransactionTimer(SIPClien
tTransaction.java:1322)

     [java] at
gov.nist.javax.sip.stack.SIPTransaction.sendMessage(SIPTransaction.java:741)

     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.sendMessage(SIPClientTransacti
on.java:486)

     [java] at
gov.nist.javax.sip.stack.SIPClientTransaction.sendRequest(SIPClientTransacti
on.java:986)

     [java] at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregiste
r(SipRegistrarConnection.java:675)

     [java] at
net.java.sip.communicator.impl.protocol.sip.SipRegistrarConnection.unregiste
r(SipRegistrarConnection.java:556)

     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.u
nregister(ProtocolProviderServiceSipImpl.java:339)
     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl$S
hutdownThread.run(ProtocolProviderServiceSipImpl.java:826)
     [java] at java.lang.Thread.run(Thread.java:619)
     [java] at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.s
hutdown(ProtocolProviderServiceSipImpl.java:801)
     [java] at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(Prot
ocolProviderFactory.java:788)
     [java] at
net.java.sip.communicator.service.protocol.ProtocolProviderFactory.stop(Prot
ocolProviderFactory.java:765)
     [java] at
net.java.sip.communicator.impl.protocol.sip.SipActivator.stop(SipActivator.j
ava:213)
     [java] at
org.apache.felix.framework.util.SecureAction.stopActivator(SecureAction.java
:611)
     [java] at
org.apache.felix.framework.Felix._stopBundle(Felix.java:2047)
     [java] at
org.apache.felix.framework.Felix.stopBundle(Felix.java:2004)
     [java] at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1188)
     [java] at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
     [java] at java.lang.Thread.run(Thread.java:619)

BUILD SUCCESSFUL
Total time: 2 minutes 59 seconds

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


#6

Hi all,

Sometimes I see the following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit instead
of graceful.

Does somebody has more insight to this?

It might be solved with a newer version of the JAIN-SIP stack.
Unfortunately, I can't reproduce the NPE. I'll be interested if you find
a way to do so.

I've been seeing the same thing, or something similar, for a while now. You
can only make one outgoing call before SC freezes up, and when I look at the
logs, there's an NPE (I don't have the logs with me so I can't check to see
if it's the same one you're seeing). My guess from my previous
investigations would be that the single sip stack changes have a bug in them
which doesnt properly recycle the sip stack. I didn't have time before the
holidays to send out the error messages yet, and I won't have access to them
again until at least Monday.

The SIP stack isn't recycled between calls. You have to unregister all
SIP accounts for it to happen.

Does the problem occur when you hang up? (see below) I've attached a
patch. Could you please try with it?

I don't think this problem was introduced with the single SIP stack patch.

The bugzilla entry dates from Oct 22 but the single SIP stack patch was
merged end of November IIRC .

For the record, there is still a bug with the single stack for which a
fix will be commited soon. Sometimes when SC receives a call, it can't
hang up. For instance, this happens when the To: field of the INVITE
doesn't match your SIP account address of record (ie you were called on
mylandlinenumber@myprovider and your account is me@myprovider).

A second bug is that JAIN-SIP stack needs to be updated for TLS to work
properly.

Just as an additional information: I see this behaviour only if the
calls are between two SC (both parties use a SC). If I call other
SIP clients (in my normal test scenario I use a _very_ old implementation
of minisip) this doesn't happen. At least I don't experience the
blocking of SC as the bug report describes.

I've just tested to call SC twice and it has worked (from a regular
phone, my SIP account has a landline phone number).

Because I rarely use a SC to SC scenario I never saw this behaviour
before.

By the way, does someone know how to test a SC to SC scenario with only
one computer? I don't think the microphone can be shared under
Linux/ALSA.

Cheers,

proxyrouter-20081228.diff (1.89 KB)

···

On Sat, Dec 27, 2008 at 02:32:50PM +0100, Werner Dittmann wrote:
On Sat, Dec 27, 2008 at 04:31:01PM -0500, Alan Kelly wrote:
On Sun, Dec 28, 2008 at 10:04:26AM +0100, Werner Dittmann wrote:
On Sun, Dec 28, 2008 at 09:52:38AM +0100, Werner Dittmann wrote:

--
Sébastien Mazy


#7

S�bastien,

to test the whole stuff on one computer I use a VMware guest system
(an openSUSE 10.2) which runs my other client. I use this old minisip
client because it has the nice feature to specify a WAV file that
will be played when you call it (sort of answering machine). Also
the received sound can be stored in a file.

The described behaviour is only if I use one SC on my Linux box and
the other one on a Windows XP (both Java 1.6). Also both are
registered.

One thought here:

My SIP registrar (Kamailio) uses the IP address 172.16.97.1:5070, a
local address to my vmnet1 adapter that connects my VMware player
guest. Kamailio also has an alias for this address. My SC on the
linux box registers to this using the following SIP URI:
100@172.16.97.1, the port numbers are set accordingly to 5070 for
the registrar and proxy.

The Windows XP system is connected to a real NIC which has the
subnetwork 192.168.200.0/24. The SC client on windows XP uses the
SIP URI 101@172.16.97.1, port numbers are also set accordingly
to 5070 for the registrar and proxy. The XP system has a default
route to the linux host.

My usual test scenario runs inside the same subnetwork (172.16.97.0/24)
and all works mostly ok. When using a SC on a second network it shows
the described behaviour.

I have two wireshark files availiable: one that shows the first
successful call, a second one the shows the failed call. Maybe the
SIP protocol data can give some hints where the problem is? If you
have wireshark available I can send you the traces.

Regards,
Werner

S�bastien Mazy schrieb:

···

Hi all,

On Sat, Dec 27, 2008 at 02:32:50PM +0100, Werner Dittmann wrote:

Sometimes I see the following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit instead
of graceful.

Does somebody has more insight to this?

It might be solved with a newer version of the JAIN-SIP stack.
Unfortunately, I can't reproduce the NPE. I'll be interested if you find
a way to do so.

On Sat, Dec 27, 2008 at 04:31:01PM -0500, Alan Kelly wrote:

I've been seeing the same thing, or something similar, for a while now. You
can only make one outgoing call before SC freezes up, and when I look at the
logs, there's an NPE (I don't have the logs with me so I can't check to see
if it's the same one you're seeing). My guess from my previous
investigations would be that the single sip stack changes have a bug in them
which doesnt properly recycle the sip stack. I didn't have time before the
holidays to send out the error messages yet, and I won't have access to them
again until at least Monday.

The SIP stack isn't recycled between calls. You have to unregister all
SIP accounts for it to happen.

Does the problem occur when you hang up? (see below) I've attached a
patch. Could you please try with it?

On Sun, Dec 28, 2008 at 10:04:26AM +0100, Werner Dittmann wrote:

I don't think this problem was introduced with the single SIP stack patch.

The bugzilla entry dates from Oct 22 but the single SIP stack patch was
merged end of November IIRC .

For the record, there is still a bug with the single stack for which a
fix will be commited soon. Sometimes when SC receives a call, it can't
hang up. For instance, this happens when the To: field of the INVITE
doesn't match your SIP account address of record (ie you were called on
mylandlinenumber@myprovider and your account is me@myprovider).

A second bug is that JAIN-SIP stack needs to be updated for TLS to work
properly.

On Sun, Dec 28, 2008 at 09:52:38AM +0100, Werner Dittmann wrote:

Just as an additional information: I see this behaviour only if the
calls are between two SC (both parties use a SC). If I call other
SIP clients (in my normal test scenario I use a _very_ old implementation
of minisip) this doesn't happen. At least I don't experience the
blocking of SC as the bug report describes.

I've just tested to call SC twice and it has worked (from a regular
phone, my SIP account has a landline phone number).

Because I rarely use a SC to SC scenario I never saw this behaviour
before.

By the way, does someone know how to test a SC to SC scenario with only
one computer? I don't think the microphone can be shared under
Linux/ALSA.

Cheers,

------------------------------------------------------------------------

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


#8

Sébastien,

Does the problem occur when you hang up? (see below) I've attached a

patch. Could you please try with it?

I am unable to reproduce the bug using the current revision. Everything
seems to work fine now. If it comes back I'll certainly take a look at your
patch.

Thanks anyways.

-Alan

···

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

From: Sébastien Mazy [mailto:melyadon@gmail.com] On Behalf Of Sébastien Mazy

Sent: Sunday, December 28, 2008 6:19 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Strange message during shutdown - SIP stack

Hi all,

On Sat, Dec 27, 2008 at 02:32:50PM +0100, Werner Dittmann wrote:

Sometimes I see the following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit
instead of graceful.

Does somebody has more insight to this?

It might be solved with a newer version of the JAIN-SIP stack.
Unfortunately, I can't reproduce the NPE. I'll be interested if you find a
way to do so.

On Sat, Dec 27, 2008 at 04:31:01PM -0500, Alan Kelly wrote:

I've been seeing the same thing, or something similar, for a while
now. You can only make one outgoing call before SC freezes up, and
when I look at the logs, there's an NPE (I don't have the logs with me
so I can't check to see if it's the same one you're seeing). My guess
from my previous investigations would be that the single sip stack
changes have a bug in them which doesnt properly recycle the sip
stack. I didn't have time before the holidays to send out the error
messages yet, and I won't have access to them again until at least Monday.

The SIP stack isn't recycled between calls. You have to unregister all SIP
accounts for it to happen.

Does the problem occur when you hang up? (see below) I've attached a patch.
Could you please try with it?

On Sun, Dec 28, 2008 at 10:04:26AM +0100, Werner Dittmann wrote:

I don't think this problem was introduced with the single SIP stack patch.

The bugzilla entry dates from Oct 22 but the single SIP stack patch
was merged end of November IIRC .

For the record, there is still a bug with the single stack for which a fix
will be commited soon. Sometimes when SC receives a call, it can't hang up.
For instance, this happens when the To: field of the INVITE doesn't match
your SIP account address of record (ie you were called on
mylandlinenumber@myprovider and your account is me@myprovider).

A second bug is that JAIN-SIP stack needs to be updated for TLS to work
properly.

On Sun, Dec 28, 2008 at 09:52:38AM +0100, Werner Dittmann wrote:

Just as an additional information: I see this behaviour only if the
calls are between two SC (both parties use a SC). If I call other SIP
clients (in my normal test scenario I use a _very_ old implementation
of minisip) this doesn't happen. At least I don't experience the
blocking of SC as the bug report describes.

I've just tested to call SC twice and it has worked (from a regular phone,
my SIP account has a landline phone number).

Because I rarely use a SC to SC scenario I never saw this behaviour
before.

By the way, does someone know how to test a SC to SC scenario with only one
computer? I don't think the microphone can be shared under Linux/ALSA.

Cheers,

--
Sébastien Mazy

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

If you still have a bug with jain-sip, let me know ( test against the
current sip stack version and please summarize the problem ). I would
be interested in fixing such issues or inspecting and accepting your
patches.

Ranga

···

On Sun, Dec 28, 2008 at 8:16 AM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Sébastien,

to test the whole stuff on one computer I use a VMware guest system
(an openSUSE 10.2) which runs my other client. I use this old minisip
client because it has the nice feature to specify a WAV file that
will be played when you call it (sort of answering machine). Also
the received sound can be stored in a file.

The described behaviour is only if I use one SC on my Linux box and
the other one on a Windows XP (both Java 1.6). Also both are
registered.

One thought here:

My SIP registrar (Kamailio) uses the IP address 172.16.97.1:5070, a
local address to my vmnet1 adapter that connects my VMware player
guest. Kamailio also has an alias for this address. My SC on the
linux box registers to this using the following SIP URI:
100@172.16.97.1, the port numbers are set accordingly to 5070 for
the registrar and proxy.

The Windows XP system is connected to a real NIC which has the
subnetwork 192.168.200.0/24. The SC client on windows XP uses the
SIP URI 101@172.16.97.1, port numbers are also set accordingly
to 5070 for the registrar and proxy. The XP system has a default
route to the linux host.

My usual test scenario runs inside the same subnetwork (172.16.97.0/24)
and all works mostly ok. When using a SC on a second network it shows
the described behaviour.

I have two wireshark files availiable: one that shows the first
successful call, a second one the shows the failed call. Maybe the
SIP protocol data can give some hints where the problem is? If you
have wireshark available I can send you the traces.

Regards,
Werner

Sébastien Mazy schrieb:

Hi all,

On Sat, Dec 27, 2008 at 02:32:50PM +0100, Werner Dittmann wrote:

Sometimes I see the following
messages when stopping SC (File->exit). Also it seems that threads are
hanging around in these cases because SC performs a "forced" exit instead
of graceful.

Does somebody has more insight to this?

It might be solved with a newer version of the JAIN-SIP stack.
Unfortunately, I can't reproduce the NPE. I'll be interested if you find
a way to do so.

On Sat, Dec 27, 2008 at 04:31:01PM -0500, Alan Kelly wrote:

I've been seeing the same thing, or something similar, for a while now. You
can only make one outgoing call before SC freezes up, and when I look at the
logs, there's an NPE (I don't have the logs with me so I can't check to see
if it's the same one you're seeing). My guess from my previous
investigations would be that the single sip stack changes have a bug in them
which doesnt properly recycle the sip stack. I didn't have time before the
holidays to send out the error messages yet, and I won't have access to them
again until at least Monday.

The SIP stack isn't recycled between calls. You have to unregister all
SIP accounts for it to happen.

Does the problem occur when you hang up? (see below) I've attached a
patch. Could you please try with it?

On Sun, Dec 28, 2008 at 10:04:26AM +0100, Werner Dittmann wrote:

I don't think this problem was introduced with the single SIP stack patch.

The bugzilla entry dates from Oct 22 but the single SIP stack patch was
merged end of November IIRC .

For the record, there is still a bug with the single stack for which a
fix will be commited soon. Sometimes when SC receives a call, it can't
hang up. For instance, this happens when the To: field of the INVITE
doesn't match your SIP account address of record (ie you were called on
mylandlinenumber@myprovider and your account is me@myprovider).

A second bug is that JAIN-SIP stack needs to be updated for TLS to work
properly.

On Sun, Dec 28, 2008 at 09:52:38AM +0100, Werner Dittmann wrote:

Just as an additional information: I see this behaviour only if the
calls are between two SC (both parties use a SC). If I call other
SIP clients (in my normal test scenario I use a _very_ old implementation
of minisip) this doesn't happen. At least I don't experience the
blocking of SC as the bug report describes.

I've just tested to call SC twice and it has worked (from a regular
phone, my SIP account has a landline phone number).

Because I rarely use a SC to SC scenario I never saw this behaviour
before.

By the way, does someone know how to test a SC to SC scenario with only
one computer? I don't think the microphone can be shared under
Linux/ALSA.

Cheers,

------------------------------------------------------------------------

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

--
M. Ranganathan

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


#10

Hi,

with build 1616 some tests and results:

1-
was able once to make a call on the LAN, but audio only one way.
All other tests resulted only in disconnects, no voice calls were possible.
ejabberd XMPP server v2.0.2 located on this LAN.

Calls are made to JID@WAN IP public address.

In router, port 5222 is forwarded from WAN to LAN IP of server.

In addition, I am using port-triggering on 5222 so any computer on the
LAN using this port will have returning packets forwarded from WAN,
port 5222, to its LAN IP address. I also trigger on ports 5223 and
7777.

This is an academic test, since I do not need LAN voice calls at this
time; I can walk to the next room or shout.

2-
was able to make two successful voice calls with good quality with two
friends from LAN at 1- to their computers behind NAT routers.

3-
changed ISP and modem/router/firewall

no problem with text chats, but impossible to make voice calls in
either direction. Attempts end in disconnection.

···

**********
Do not understand why text chat works, but XMPP voice calls are unable
to complete? If there was a firewall or port-forwarding problem, why are
text msgs working with no problems?
***********

This router firewall has a symmetric NAT, which sometimes causes problems
because it is so strict.

4-
Server is ejabberd v2.0.2 running on the LAN located at 1-

5-
I have two other modem/routers which I will try - and will see what
differences there are.

regards, Earl

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


#11

Hi,

I was finally able to make an XMPP voice call over the Inet, passing
two NAT routers. Voice quality was good.

I did not see any padlocks. Does build 1616 and later automatically
use voice encryption on XMPP calls?

I have not yet tried file transfer, is this supported in SC - and will
file transfers be encrypted ?

regards, Earl

···

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


#12

Hi,

I would like to suggest the following default codec order.

ilbc
speex
gsm
g723
g728
ALAW
uLAW
dvi (why are there two identrical codecs here?)

As I understand it dvi codec is for video and therefore not so
suitable for audio ???

Does anyone have any problems with the above suggested default
order?

My thinking was that ilbc and speex belong at the top because they
are resistant to packet loss and need low bandwidth.

···

******
Has anyone noticed that SC appears to change the codec order
by itself ?

If yes, this is a bug.
*******

Regards, Earl

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

in the ADD CONTACT WIZARD there is a button called
"Add account" that is very disturbing for normal users.

This button does not belong in this wizard and should be
removed.

See image.

Regards, Earl


#14

Earl,

if you refer to ZRTP enabled voice encryption then I'm pretty sure that
this was not yet fully implemented. AFAIK XMPP call setup implementation
in SC differs from the call setup for SC. To implement ZRTP enabled
encryption for XMPP calls I would probably need some support to understand
the mechanics how XMPP sets up voice calls.

Regards,
Werner

Earl schrieb:

···

Hi,

I was finally able to make an XMPP voice call over the Inet, passing
two NAT routers. Voice quality was good.

I did not see any padlocks. Does build 1616 and later automatically
use voice encryption on XMPP calls?

I have not yet tried file transfer, is this supported in SC - and will
file transfers be encrypted ?

regards, Earl

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

I have found that normal people are not capable of clicking the
drop-down selection arrow in order to change the network
from AIM to Jabber, before creating a Jabber account in
"ADD NEW ACCOUNT". They end up creating a non
desired AIM account instead of a Jabber account.

It is my belief that SC should be supporting open-source sw
and not closed-source.

I therefore make a very strong suggestion to have Jabber
as the default that appears in the network window and not
AIM.

See image.

Regards, Earl


#16

Werner,

Peter Saint Andre, who is also a member of this list, but very busy with XMPP and
Jingle protocol standardization and therefore may not have read this, knows the
corresponding specifications very well.

I have taken the liberty to contact him and asked him to support you.

Regards, Earl

Werner Dittmann wrote:

···

Earl,

if you refer to ZRTP enabled voice encryption then I'm pretty sure that
this was not yet fully implemented. AFAIK XMPP call setup implementation
in SC differs from the call setup for SC. To implement ZRTP enabled
encryption for XMPP calls I would probably need some support to understand
the mechanics how XMPP sets up voice calls.

Regards,
Werner

Earl schrieb:
  

Hi,

I was finally able to make an XMPP voice call over the Inet, passing
two NAT routers. Voice quality was good.

I did not see any padlocks. Does build 1616 and later automatically
use voice encryption on XMPP calls?

I have not yet tried file transfer, is this supported in SC - and will
file transfers be encrypted ?

regards, Earl

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


#17

Hi Earl, all,

I don't agree with you Earl, IMHO it's important to let the user
create an account here. Imagine the case of an user who want to
activate one of his accounts and who finally notice that the account
he is looking for is missing, I'm quite sure that he would be very
happy to be able to create this missing account directly from here.

What do you all think ?

Cheers,

Ben

···

2008/12/29 Earl <Large.Files@gmx.net>:

Hi,

in the ADD CONTACT WIZARD there is a button called
"Add account" that is very disturbing for normal users.

This button does not belong in this wizard and should be
removed.

See image.

Regards, Earl

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


#18

Hi,

I brought this up before and I hope I did not forget to enter an issue.

When registration is lost, SC should either

* silently re-register every minute or
* allow manual registration

Manual re-registration could either be for all accounts, or have a
drop-down menu to choose a particular account to re-register.

See image.

Regards, Earl


#19

Hi,

the present CALL VIA line is very short and if multiple accounts are
configured, the only way to know which account will be used for an
outgoing call is to remember what a number means.

Most people, including myself, are not capable of remembering that
account 3 is at abc.com, that account 4 is at jabber.org, or account
5 is at def.net.

I suggest making the line longer so it can be easily seen which account
will be used for the call.

See image.

Regards, Earl


#20

Hi Benoit,

A user who wants to activate one of his accounts should not be using the
create contact window. Users should be *forced* to create accounts by
using File/Add new account -or- Tools/Options/accounts. These two
possibilities are more than enough.

I watch non-developers / non-programmers try to do things with SC and
see the mistakes they make. The average user has ***terrible*** problems
with adding a contact because they will ** almost always ** click the
Add Account button instead of clicking the NEXT button.

In my opinion, keeping the Add Account button in this Add Contact menu
will cause no end of problems with users. It must be removed.

The explanation text could be expanded as follows:

The list below contains all registered accounts. Select the one you would
like to use to communicate with the new contact by clicking the corresponding
box. If you do not see the account you wish to use, you may cancel and
use the File / Add New Account menu to create one.

Is "select the one" exactly correct - or - should it read "select one or more
account(s) you would like ......." ?

I added the part about clicking the corresponding box because I have seen
users highlight an account by clicking on it and thinking that this has selected
the account. They did not understand the box had to be checked. This
brings up the question whether clicking on an account should toggle both
high-lighting *AND* check in the box ? The first click selects that account
and the second click on the same account unselects it again.

If a user asks the question "why does clicking on an account cause high-
lighting, but not selection?" it is not possible to give an answer.

Another question would be "why does the column with the check boxes
have no header title" ? It could say, for example, "click one or more boxes
to select account(s). If needed, the large icon on the left could be made smaller
to give additional room.

Another question is why is there more than one protocol on this page?
Should not the user be forced to make a protocol decision before being allowed
to select account(s) ? The user could select a SIP account to use with a
contact that only has a Jabber ID, for example. Is it desirable to let the user
do this?

Regards, Earl

Benoit Pradelle wrote:

···

Hi Earl, all,

I don't agree with you Earl, IMHO it's important to let the user
create an account here. Imagine the case of an user who want to
activate one of his accounts and who finally notice that the account
he is looking for is missing, I'm quite sure that he would be very
happy to be able to create this missing account directly from here.

What do you all think ?

Cheers,

Ben

2008/12/29 Earl <Large.Files@gmx.net>:
  

Hi,

in the ADD CONTACT WIZARD there is a button called
"Add account" that is very disturbing for normal users.

This button does not belong in this wizard and should be
removed.

See image.

Regards, Earl

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