[jitsi-dev] Problem handle SDP correct


#1

Hello,

I'm using the nighly build from 24th of July (v2.3-4760) and having with
asterisk and Customer Interaction Center a problem with SDP. I receive a
Java error like this:

net.java.sip.communicator.service.protocol.OperationFailedException: An
error occurred while sending invite request
    at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.throwOperationFailedException(ProtocolProviderServiceSipImpl.java:2420)
    at
net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.invite(CallPeerSipImpl.java:1498)
    at
net.java.sip.communicator.impl.protocol.sip.CallSipImpl.invite(CallSipImpl.java:388)
    at
net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.createOutgoingCall(OperationSetBasicTelephonySipImpl.java:174)
    at
net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.createCall(OperationSetBasicTelephonySipImpl.java:119)
    at
net.java.sip.communicator.service.protocol.media.AbstractOperationSetBasicTelephony.createCall(AbstractOperationSetBasicTelephony.java:110)
    at
net.java.sip.communicator.impl.gui.main.call.CallManager.internalCall(CallManager.java:2312)
    at
net.java.sip.communicator.impl.gui.main.call.CallManager.access$800(CallManager.java:48)
    at
net.java.sip.communicator.impl.gui.main.call.CallManager$CreateCallThread.run(CallManager.java:2194)
Caused by:
net.java.sip.communicator.service.protocol.OperationFailedException: An
error occurred while creating session description
    at
net.java.sip.communicator.impl.protocol.sip.ProtocolProviderServiceSipImpl.throwOperationFailedException(ProtocolProviderServiceSipImpl.java:2420)
    at
net.java.sip.communicator.impl.protocol.sip.sdp.SdpUtils.createSessionDescription(SdpUtils.java:196)
    at
net.java.sip.communicator.impl.protocol.sip.CallPeerMediaHandlerSipImpl.createFirstOffer(CallPeerMediaHandlerSipImpl.java:142)
    at
net.java.sip.communicator.impl.protocol.sip.CallPeerMediaHandlerSipImpl.createOffer(CallPeerMediaHandlerSipImpl.java:117)
    at
net.java.sip.communicator.impl.protocol.sip.CallPeerSipImpl.invite(CallPeerSipImpl.java:1481)
    ... 7 more
Caused by: javax.sdp.SdpException: The parameter is null
    at
gov.nist.javax.sdp.SessionDescriptionImpl.setOrigin(SessionDescriptionImpl.java:480)
    at javax.sdp.SdpFactory.createSessionDescription(SdpFactory.java:79)
    at
net.java.sip.communicator.impl.protocol.sip.sdp.SdpUtils.createSessionDescription(SdpUtils.java:145)
    ... 10 more

Please find attached the log and pcap files. The OS is opensuse 12.3 x64
and the Java is

java-1_7_0-openjdk- Java runtime environment based on OpenJDK 7 and
IcedTea 7

Alternative Version

Installierte Version

Version:

1.7.0.6-8.14.5

1.7.0.6-8.14.5

Erstellt am:

Fr 03 Mai 2013 23:46:50 CEST

Fr 03 Mai 2013 23:46:50 CEST

Installiert am:

Mo 15 Jul 2013 17:29:10 CEST

Paketgruppe:

Development/Languages/Java

Development/Languages/Java

Lizenz:

GPL-2.0-with-classpath-exception

GPL-2.0-with-classpath-exception

Installierte Größe:

53,9 MiB

53,9 MiB

Downloadgröße:

37,6 MiB

0 B

Distribution:

openSUSE 12.3

Anbieter:

openSUSE

openSUSE

Paketersteller:

http://bugs.opensuse.org

http://bugs.opensuse.org

Architektur:

x86_64

x86_64

Erzeugt auf:

URL:

http://icedtea.classpath.org

http://icedtea.classpath.org

Quellpaket

java-1_7_0-openjdk-1.7.0.6-8.14.5

java-1_7_0-openjdk-1.7.0.6-8.14.5

Medium Nr.:

0

0

Autoren:

Regards
Alex

jitsi0.log.0 (96.9 KB)

jitsi0.log.0.lck (0 Bytes)

jitsi0.log.1 (21.3 KB)

jitsi0.log.2 (38.9 KB)

jitsi0.pcap (722 KB)

jitsi1.pcap (10 KB)

jitsi2.pcap (11.2 KB)

···

--
Mit freundlichen Grüßen
Alexander Nolting

almano generating contacts GmbH

________________________________________

Bleichstraße 1 • 33607 Bielefeld • Telefon +49 521 32922269 • Mobil +49 173 5322338

www.almano.decontact@almano.de

Geschäftsführung: Alexander Nolting

Amtsgericht: Bielefeld • HRB 38883 • USt-ID 252781292


#2

I'm using the nighly build from 24th of July (v2.3-4760) and having with
asterisk and Customer Interaction Center a problem with SDP. I receive a Java
error like this:

[...]

We need the IP address your machine to create the SDP. Trying to get this fails because the your machine, linux-gwd0.site, doesn't seem to know its own name. Please make sure that if you ping linux-gwd0.site on /your/ computer that it returns an IP address.

Please find attached the log and pcap files. The OS is opensuse 12.3 x64 and
the Java is

java-1_7_0-openjdk - Java runtime environment based on OpenJDK 7 and
IcedTea 7

[...]

Regards
Alex

Ingo


#3

Hi Ingo,

that's not that easy. I'm testing in a closed environment which has no
SIP trunk to an CO and I can't give access immediately.
I will see what I can arrange.

Regards
Alex

···

Am 25.07.2013 19:00, schrieb Ingo Bauersachs:

I'm using the nighly build from 24th of July (v2.3-4760) and having with
asterisk and Customer Interaction Center a problem with SDP. I receive a Java
error like this:

[...]

We need the IP address your machine to create the SDP. Trying to get this fails because the your machine, linux-gwd0.site, doesn't seem to know its own name. Please make sure that if you ping linux-gwd0.site on /your/ computer that it returns an IP address.

Please find attached the log and pcap files. The OS is opensuse 12.3 x64 and
the Java is

java-1_7_0-openjdk - Java runtime environment based on OpenJDK 7 and
IcedTea 7

[...]

Regards
Alex

Ingo

--
Mit freundlichen Grüßen
Alexander Nolting

almano generating contacts GmbH

________________________________________

Bleichstraße 1 • 33607 Bielefeld • Telefon +49 521 32922269 • Mobil +49 173 5322338

www.almano.decontact@almano.de

Geschäftsführung: Alexander Nolting

Amtsgericht: Bielefeld • HRB 38883 • USt-ID 252781292


#4

that's not that easy. I'm testing in a closed environment which has no
SIP trunk to an CO and I can't give access immediately.
I will see what I can arrange.

Hm? Well, with 'we' I actually meant Jitsi. 'we' as in people don't need any access :slight_smile:

Regards
Alex

Ingo


#5

After some re-readings I came to the same point :smiley:

OK. But this shouldn't be an issue as this is a very common situation
that OS is working in an environment where the maschine name can't be
resolved from DNS.

Regards
Alex

···

Am 25.07.2013 19:07, schrieb Ingo Bauersachs:

that's not that easy. I'm testing in a closed environment which has no
SIP trunk to an CO and I can't give access immediately.
I will see what I can arrange.

Hm? Well, with 'we' I actually meant Jitsi. 'we' as in people don't need any access :slight_smile:

Regards
Alex

Ingo

--
Mit freundlichen Grüßen
Alexander Nolting

almano generating contacts GmbH

________________________________________

Bleichstraße 1 • 33607 Bielefeld • Telefon +49 521 32922269 • Mobil +49 173 5322338

www.almano.decontact@almano.de

Geschäftsführung: Alexander Nolting

Amtsgericht: Bielefeld • HRB 38883 • USt-ID 252781292


#6

After some re-readings I came to the same point :smiley:

Sorry, I could have been clearer.

OK. But this shouldn't be an issue as this is a very common situation
that OS is working in an environment where the maschine name can't be
resolved from DNS.

It doesn't need to be resolvable from DNS. /etc/hosts is enough, but the name your machine is using must resolve to an address.

Regards
Alex

Ingo


#7

Why?

Let me explain the situation and how this is handled by the Interaction
Client for CIC (Customer Interaction Center) and twinkle. I'm having a
laptop which is completely independed of an network in case name
resolving. That means to follow the that name opensuse is giving it ends
to .site (if this is a correct behavior is another discussion which was
ongoing a couple of weeks ago). So if I'm working on Customer Site I
will (probably) receive a repsonse to the dhcp request which give me an
IP and one or a list of nameservers. With this set of of information I'm
able to access network devices and the Internet. See below:

linux-gwd0:/home/anolting # ifconfig
eth0 Link encap:Ethernet Hardware Adresse 00:26:B9:ED:AF:7F
          inet Adresse:10.67.111.112 Bcast:10.67.111.255
Maske:255.255.255.0
          inet6 Adresse: fe80::226:b9ff:feed:af7f/64
Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:724628 errors:0 dropped:0 overruns:0 frame:0
          TX packets:282597 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000
          RX bytes:822068427 (783.9 Mb) TX bytes:41366102 (39.4 Mb)
          Interrupt:22 Speicher:f6fe0000-f7000000

lo Link encap:Lokale Schleife
          inet Adresse:127.0.0.1 Maske:255.0.0.0
          inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:7827 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7827 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:0
          RX bytes:431937 (421.8 Kb) TX bytes:431937 (421.8 Kb)

wlan0 Link encap:Ethernet Hardware Adresse 00:24:D6:69:11:28
          inet Adresse:192.168.23.123 Bcast:192.168.23.255
Maske:255.255.252.0
          inet6 Adresse: fe80::224:d6ff:fe69:1128/64
Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:210818 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63246 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000
          RX bytes:189020789 (180.2 Mb) TX bytes:6846514 (6.5 Mb)

linux-gwd0:/home/anolting # hostname
linux-gwd0.site
linux-gwd0:/home/anolting # cat /etc/resolv.conf
### /etc/resolv.conf file autogenerated by netconfig!

···

#
# Before you change this file manually, consider to define the
# static DNS configuration using the following variables in the
# /etc/sysconfig/network/config file:
# NETCONFIG_DNS_STATIC_SEARCHLIST
#
NETCONFIG_DNS_STATIC_SERVERS

#
NETCONFIG_DNS_FORWARDER

# or disable DNS configuration updates via netconfig by
setting:

#
NETCONFIG_DNS_POLICY=''

#

# See also the netconfig(8) manual page and other
documentation.

#

# Note: Manual change of this file disables netconfig too,
but

# may get lost when this file contains comments or empty
lines

# only, the netconfig settings are same with settings in
this

# file and in case of a "netconfig update -f"
call.

#

### Please remove (at least) this line when you modify the
file!

search s**.s***.net
cache03.s******.ch

nameserver
192.168.88.26

nameserver
192.168.88.29

nameserver
192.168.55.155

linux-gwd0:/home/anolting #

If an sip cabale application now tries to contact a server and the
machines name couldn't be resolved it should use the local ip address of
the maschine. This is what IC Client and twinkle is doing. From my
humble opinion :wink:

Regards
Alex

Am 25.07.2013 19:29, schrieb Ingo Bauersachs:

After some re-readings I came to the same point :smiley:

Sorry, I could have been clearer.

OK. But this shouldn't be an issue as this is a very common situation
that OS is working in an environment where the maschine name can't be
resolved from DNS.

It doesn't need to be resolvable from DNS. /etc/hosts is enough, but the name your machine is using must resolve to an address.

Regards
Alex

Ingo

--
Mit freundlichen Grüßen
Alexander Nolting

almano generating contacts GmbH

________________________________________

Bleichstraße 1 • 33607 Bielefeld • Telefon +49 521 32922269 • Mobil +49 173 5322338

www.almano.decontact@almano.de

Geschäftsführung: Alexander Nolting

Amtsgericht: Bielefeld • HRB 38883 • USt-ID 252781292


#8

Why?

All I can tell is that the SIP implementation (the Java reference impl. from NIST) is calling "InetAddress.getLocalHost()", which fails on your system and is causing the NullPointerException. On my Win7 box, this returns unqualified-systemname/192.168.10.23 (the DHCP address) and on a Fedora 15 box, this returns unqualified-systemname/127.0.0.1.

Let me explain the situation and how this is handled by the Interaction
Client for CIC (Customer Interaction Center) and twinkle. I'm having a
laptop which is completely independed of an network in case name
resolving. That means to follow the that name opensuse is giving it ends
to .site (if this is a correct behavior is another discussion which was
ongoing a couple of weeks ago).

So having the .site and hence an FQDN is weird.

So if I'm working on Customer Site I
will (probably) receive a repsonse to the dhcp request which give me an
IP and one or a list of nameservers. With this set of of information I'm
able to access network devices and the Internet. See below:

[...]

If an sip cabale application now tries to contact a server and the
machines name couldn't be resolved it should use the local ip address of
the maschine. This is what IC Client and twinkle is doing. From my
humble opinion :wink:

This is what Jitsi's trying to obtain: the local IP address. And it fails because Java is trying to lookup linux-gwd0.site.

Regards
Alex

Ingo


#9

Hey folks,

Why?

All I can tell is that the SIP implementation (the Java reference
impl. from NIST) is calling "InetAddress.getLocalHost()", which fails
on your system and is causing the NullPointerException. On my Win7
box, this returns unqualified-systemname/192.168.10.23 (the DHCP
address) and on a Fedora 15 box, this returns
unqualified-systemname/127.0.0.1.

Actually we go to great lengths not to rely on InetAddress.getLocalHost() for anything important because it has always been quite unreliable. Most often however, the issue has been that it returns 127.0.0.1. This is the first time I am seeing it actually throw an exception.

In this case the culprit seems to be FMJ though, so we can fix this and construct the RTCP CNAME in a better way.

Opening an issue would be nice since I am not sure at what point we would be able to look into the matter.

Emil

···

On 25.07.13, 20:34, Ingo Bauersachs wrote:

Let me explain the situation and how this is handled by the
Interaction Client for CIC (Customer Interaction Center) and
twinkle. I'm having a laptop which is completely independed of an
network in case name resolving. That means to follow the that name
opensuse is giving it ends to .site (if this is a correct behavior
is another discussion which was ongoing a couple of weeks ago).

So having the .site and hence an FQDN is weird.

So if I'm working on Customer Site I will (probably) receive a
repsonse to the dhcp request which give me an IP and one or a list
of nameservers. With this set of of information I'm able to access
network devices and the Internet. See below:

[...]

If an sip cabale application now tries to contact a server and the
machines name couldn't be resolved it should use the local ip
address of the maschine. This is what IC Client and twinkle is
doing. From my humble opinion :wink:

This is what Jitsi's trying to obtain: the local IP address. And it
fails because Java is trying to lookup linux-gwd0.site.

Regards Alex

Ingo

_______________________________________________ dev mailing list
dev@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#10

Actually we go to great lengths not to rely on
InetAddress.getLocalHost() for anything important because it has always
been quite unreliable. Most often however, the issue has been that it
returns 127.0.0.1. This is the first time I am seeing it actually throw
an exception.

In this case the culprit seems to be FMJ though, so we can fix this and
construct the RTCP CNAME in a better way.

It's in JSIP, not FMJ.

Opening an issue would be nice since I am not sure at what point we
would be able to look into the matter.

Emil

Ingo


#11

Actually we go to great lengths not to rely on
InetAddress.getLocalHost() for anything important because it has always
been quite unreliable. Most often however, the issue has been that it
returns 127.0.0.1. This is the first time I am seeing it actually throw
an exception.

In this case the culprit seems to be FMJ though, so we can fix this and
construct the RTCP CNAME in a better way.

It's in JSIP, not FMJ.

Actually, it's in both. There's a problem with the construction of the origin (which is JAIN SDP) and there are problems with the construction of RTCP CNAMEs which come from FMJ.

Emil

···

On 25.07.13, 22:54, Ingo Bauersachs wrote:

Opening an issue would be nice since I am not sure at what point we
would be able to look into the matter.

Emil

Ingo

--
https://jitsi.org