[jitsi-dev] Fwd: Bug#735413: calls from JSCommunicator to Jitsi fail


#1

Package: jitsi
Version: 2.3.4952-1

I try to make an audio call from JSCommunicator to Jitsi

Jitsi alerts me about the incoming call. Before starting to ring, Jitsi
logs an exception to the console (see below), I'm not sure if this is
from the INVITE session or some other transaction like registration or
presence.

When I answer, the in-call window appears with state "Connecting", a SIP
200 OK is sent and it just stays in the "Connecting phase", it never
really connects.

Looking at the SDP sent in the 200 message, I notice

m=audio 5004 RTP/SAVPF 111 0 8 126

however there are no a=crypto lines present. Changing the SRTP settings
in the SIP account, I enable the SDES checkbox, now it includes a crypto
line in the SDP response.

Maybe when Jitsi receives an INVITE with SRTP it should automatically be
replying with SRTP, even if SRTP is disabled. Sending RTP/SAVPF without
a crypto line seems to be a bug.

Despite getting the crypto line in there now with SDES enabled, the call
still fails, JSCommunicator does not like the SDP from Jitsi and logs a
message:

SetRemoteDescription failed: Failed to update session state: ERROR_CONTENT

This is the exception that appears regularly in the console:

09:32:07.061 SEVERE: [17] impl.protocol.sip.SipLogger.logPacket().390
Cannot obtain message body
java.lang.NullPointerException
        at gov.nist.javax.sip.stack.MessageChannel.getKey(MessageChannel.java:313)
        at
gov.nist.javax.sip.stack.TLSMessageProcessor.createMessageChannel(TLSMessageProcessor.java:296)
        at
gov.nist.javax.sip.stack.SIPTransactionStack.getLocalAddressForTlsDst(SIPTransactionStack.java:640)
        at
net.java.sip.communicator.impl.protocol.sip.SipLogger.getLocalAddressForDestination(SipLogger.java:492)
        at
net.java.sip.communicator.impl.protocol.sip.SipLogger.logPacket(SipLogger.java:293)
        at
net.java.sip.communicator.impl.protocol.sip.SipLogger.logMessage(SipLogger.java:253)
        at
net.java.sip.communicator.impl.protocol.sip.SipLogger.logMessage(SipLogger.java:235)
        at
gov.nist.javax.sip.stack.MessageChannel.logMessage(MessageChannel.java:390)
        at
gov.nist.javax.sip.stack.SIPServerTransaction.resendLastResponseAsBytes(SIPServerTransaction.java:1204)
        at
gov.nist.javax.sip.stack.SIPDialog$DialogTimerTask.runTask(SIPDialog.java:531)
        at
gov.nist.javax.sip.stack.timers.DefaultSipTimer$DefaultTimerTask.run(DefaultSipTimer.java:63)
        at java.util.TimerThread.mainLoop(Timer.java:512)
        at java.util.TimerThread.run(Timer.java:462)

···

---------- Forwarded message ----------
From: Daniel Pocock <daniel@pocock.com.au>
Date: Wed, Jan 15, 2014 at 10:43 AM
Subject: Bug#735413: calls from JSCommunicator to Jitsi fail
To: Debian Bug Tracking System <submit@bugs.debian.org>


#2

Hey Daniel,

Same comment about the venue. Please use our dev list for this :slight_smile:

The main problem for WebRTC compatibility with Jitsi's SIP accounts is our current lack of ICE support. This is (still) pending and the lag is my fault.

Emil

···

On 15.01.14, 09:54, Damian Minkov wrote:

---------- Forwarded message ----------
From: Daniel Pocock <daniel@pocock.com.au>
Date: Wed, Jan 15, 2014 at 10:43 AM
Subject: Bug#735413: calls from JSCommunicator to Jitsi fail
To: Debian Bug Tracking System <submit@bugs.debian.org>

Package: jitsi
Version: 2.3.4952-1

I try to make an audio call from JSCommunicator to Jitsi

Jitsi alerts me about the incoming call. Before starting to ring, Jitsi
logs an exception to the console (see below), I'm not sure if this is
from the INVITE session or some other transaction like registration or
presence.

When I answer, the in-call window appears with state "Connecting", a SIP
200 OK is sent and it just stays in the "Connecting phase", it never
really connects.

Looking at the SDP sent in the 200 message, I notice

m=audio 5004 RTP/SAVPF 111 0 8 126

however there are no a=crypto lines present. Changing the SRTP settings
in the SIP account, I enable the SDES checkbox, now it includes a crypto
line in the SDP response.

Maybe when Jitsi receives an INVITE with SRTP it should automatically be
replying with SRTP, even if SRTP is disabled. Sending RTP/SAVPF without
a crypto line seems to be a bug.

Despite getting the crypto line in there now with SDES enabled, the call
still fails, JSCommunicator does not like the SDP from Jitsi and logs a
message:

SetRemoteDescription failed: Failed to update session state: ERROR_CONTENT

This is the exception that appears regularly in the console:

09:32:07.061 SEVERE: [17] impl.protocol.sip.SipLogger.logPacket().390
Cannot obtain message body
java.lang.NullPointerException
         at gov.nist.javax.sip.stack.MessageChannel.getKey(MessageChannel.java:313)
         at
gov.nist.javax.sip.stack.TLSMessageProcessor.createMessageChannel(TLSMessageProcessor.java:296)
         at
gov.nist.javax.sip.stack.SIPTransactionStack.getLocalAddressForTlsDst(SIPTransactionStack.java:640)
         at
net.java.sip.communicator.impl.protocol.sip.SipLogger.getLocalAddressForDestination(SipLogger.java:492)
         at
net.java.sip.communicator.impl.protocol.sip.SipLogger.logPacket(SipLogger.java:293)
         at
net.java.sip.communicator.impl.protocol.sip.SipLogger.logMessage(SipLogger.java:253)
         at
net.java.sip.communicator.impl.protocol.sip.SipLogger.logMessage(SipLogger.java:235)
         at
gov.nist.javax.sip.stack.MessageChannel.logMessage(MessageChannel.java:390)
         at
gov.nist.javax.sip.stack.SIPServerTransaction.resendLastResponseAsBytes(SIPServerTransaction.java:1204)
         at
gov.nist.javax.sip.stack.SIPDialog$DialogTimerTask.runTask(SIPDialog.java:531)
         at
gov.nist.javax.sip.stack.timers.DefaultSipTimer$DefaultTimerTask.run(DefaultSipTimer.java:63)
         at java.util.TimerThread.mainLoop(Timer.java:512)
         at java.util.TimerThread.run(Timer.java:462)

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

--
https://jitsi.org


#3

The ICE support is actually not so critical in every case, the WebRTC
user will have a relay IP and Jitsi would talk to that by default if it
doesn't recognise the ICE candidates (and if the WebRTC is well behaved
when talking to a non-ICE peer)

ICE in Jitsi is only essential for Jitsi to Jitsi calls across NAT
boundaries

···

On 15/01/14 19:23, Emil Ivov wrote:

Hey Daniel,

Same comment about the venue. Please use our dev list for this :slight_smile:

The main problem for WebRTC compatibility with Jitsi's SIP accounts is
our current lack of ICE support. This is (still) pending and the lag is
my fault.


#4

Hey Daniel,

Same comment about the venue. Please use our dev list for this :slight_smile:

The main problem for WebRTC compatibility with Jitsi's SIP accounts is
our current lack of ICE support. This is (still) pending and the lag is
my fault.

The ICE support is actually not so critical

It actually is, because it is impossible to establish and maintain an RTP session with a WebRTC client unless you support ICE.

in every case, the WebRTC
user will have a relay IP and Jitsi would talk to that by default if it
doesn't recognise the ICE candidates (and if the WebRTC is well behaved
when talking to a non-ICE peer)

It's not about being well-behaved but about preventing voice hammer attacks. Browsers that don't require ICE could be very easily instructed to send audio and video to any location in the world.

This would make it painfully easy to DDOS entire data centers through a simple JS injection. DNS amplification that caused last years most substantial DDOS attacks only provides a fraction of the leverage that WebRTC voice hammers would if they didn't require ICE.

Emil

···

On 15.01.14, 19:48, Daniel Pocock wrote:

On 15/01/14 19:23, Emil Ivov wrote:

--
https://jitsi.org


#5

I agree that is a valid concern on the public Internet

What I was thinking about (and the reason I would be happy to start
using it even without ICE for now) is the cases where people are using
it on an enterprise LAN or just needing something to run quickly so they
can start developing other solutions around this technology while
waiting for everything to stabilize.

···

On 15/01/14 19:57, Emil Ivov wrote:

On 15.01.14, 19:48, Daniel Pocock wrote:

On 15/01/14 19:23, Emil Ivov wrote:

Hey Daniel,

Same comment about the venue. Please use our dev list for this :slight_smile:

The main problem for WebRTC compatibility with Jitsi's SIP accounts is
our current lack of ICE support. This is (still) pending and the lag is
my fault.

The ICE support is actually not so critical

It actually is, because it is impossible to establish and maintain an
RTP session with a WebRTC client unless you support ICE.

in every case, the WebRTC
user will have a relay IP and Jitsi would talk to that by default if it
doesn't recognise the ICE candidates (and if the WebRTC is well behaved
when talking to a non-ICE peer)

It's not about being well-behaved but about preventing voice hammer
attacks. Browsers that don't require ICE could be very easily instructed
to send audio and video to any location in the world.

This would make it painfully easy to DDOS entire data centers through a
simple JS injection. DNS amplification that caused last years most
substantial DDOS attacks only provides a fraction of the leverage that
WebRTC voice hammers would if they didn't require ICE.


#6

I think you may have missed my point.

This is not up to Jitsi. No WebRTC browser would accept to talk to a non-ICE supporting endpoint.

Emil

···

On 15.01.14, 20:02, Daniel Pocock wrote:

On 15/01/14 19:57, Emil Ivov wrote:

On 15.01.14, 19:48, Daniel Pocock wrote:

On 15/01/14 19:23, Emil Ivov wrote:

Hey Daniel,

Same comment about the venue. Please use our dev list for this :slight_smile:

The main problem for WebRTC compatibility with Jitsi's SIP accounts is
our current lack of ICE support. This is (still) pending and the lag is
my fault.

The ICE support is actually not so critical

It actually is, because it is impossible to establish and maintain an
RTP session with a WebRTC client unless you support ICE.

in every case, the WebRTC
user will have a relay IP and Jitsi would talk to that by default if it
doesn't recognise the ICE candidates (and if the WebRTC is well behaved
when talking to a non-ICE peer)

It's not about being well-behaved but about preventing voice hammer
attacks. Browsers that don't require ICE could be very easily instructed
to send audio and video to any location in the world.

This would make it painfully easy to DDOS entire data centers through a
simple JS injection. DNS amplification that caused last years most
substantial DDOS attacks only provides a fraction of the leverage that
WebRTC voice hammers would if they didn't require ICE.

I agree that is a valid concern on the public Internet

What I was thinking about (and the reason I would be happy to start
using it even without ICE for now) is the cases where people are using
it on an enterprise LAN or just needing something to run quickly so they
can start developing other solutions around this technology while
waiting for everything to stabilize.

--
https://jitsi.org


#7

I do understand your point, I do not expect Jitsi developers to be
providing people with help with their web browsers

However, it is also the nature of free software that people can use it
in any way they wish. If somebody wants to configure or patch their
browser to
fall back to vanilla SDP/RTP without ICE, they are free to do it (but
given the issues you have described, I doubt that any major Linux
distribution would carry such patches or forked versions)

···

On 15/01/14 20:19, Emil Ivov wrote:

On 15.01.14, 20:02, Daniel Pocock wrote:

On 15/01/14 19:57, Emil Ivov wrote:

On 15.01.14, 19:48, Daniel Pocock wrote:

On 15/01/14 19:23, Emil Ivov wrote:

Hey Daniel,

Same comment about the venue. Please use our dev list for this :slight_smile:

The main problem for WebRTC compatibility with Jitsi's SIP
accounts is
our current lack of ICE support. This is (still) pending and the
lag is
my fault.

The ICE support is actually not so critical

It actually is, because it is impossible to establish and maintain an
RTP session with a WebRTC client unless you support ICE.

in every case, the WebRTC
user will have a relay IP and Jitsi would talk to that by default
if it
doesn't recognise the ICE candidates (and if the WebRTC is well
behaved
when talking to a non-ICE peer)

It's not about being well-behaved but about preventing voice hammer
attacks. Browsers that don't require ICE could be very easily
instructed
to send audio and video to any location in the world.

This would make it painfully easy to DDOS entire data centers through a
simple JS injection. DNS amplification that caused last years most
substantial DDOS attacks only provides a fraction of the leverage that
WebRTC voice hammers would if they didn't require ICE.

I agree that is a valid concern on the public Internet

What I was thinking about (and the reason I would be happy to start
using it even without ICE for now) is the cases where people are using
it on an enterprise LAN or just needing something to run quickly so they
can start developing other solutions around this technology while
waiting for everything to stabilize.

I think you may have missed my point.

This is not up to Jitsi. No WebRTC browser would accept to talk to a
non-ICE supporting endpoint.