[jitsi-users] SCTP connection with ... not ready yet.


#1

Some times happens this situation in our jitsi-meet deployment. Some
participant can not listen anymore to another participant and the
jvb.log throws a lot of messages like this for that peer of the meeting:

   ...
   org.jitsi.videobridge.Endpoint.log() SCTP connection with bd5a6d5b
not ready yet.
   ...

Those messages start after this message:

<pre>
JVB 2016-11-03 11:07:32.919 INFO: [170]
org.jitsi.videobridge.xmpp.ComponentImpl.log() RECV: <iq type=“get”
to=“jitsi-videobridge.jitsi.mydomainexample.com
from="focus@auth.jitsi.mydomainexample.com/focus161788377478645"
id=“4WKTW-373328”><conference xmlns=“http://jitsi.org/protocol/colibri
id=“78f2f5db865d8d9c” name=“tools”><content name=“audio”><channel
endpoint=“3867d61a” adaptive-last-n=“false” channel-bundle-id=“3867d61a”
initiator=“true” simulcast-mode=“REWRITING” last-n="-1"
adaptive-simulcast=“true”><payload-type name=“opus” clockrate=“48000”
id=“111” channels=“2”><parameter value=“10” name=“minptime”/><parameter
value=“1” name=“useinbandfec”/></payload-type><payload-type id=“103”
name=“ISAC” clockrate=“16000”/><payload-type id=“104” name=“ISAC”
clockrate=“32000”/><payload-type id=“126” name=“telephone-event”
clockrate=“8000”/><rtp-hdrext id=“1”
uri=“urn:ietf:params:rtp-hdrext:ssrc-audio-level”/><rtp-hdrext id=“3”
uri=“http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time”/></channel></content><content
name=“video”><channel endpoint=“3867d61a” adaptive-last-n=“false”
channel-bundle-id=“3867d61a” initiator=“true” simulcast-mode=“REWRITING”
last-n="-1" adaptive-simulcast=“true”><payload-type id=“100” name=“VP8”
clockrate=“90000”><rtcp-fb xmlns=“urn:xmpp:jingle:apps:rtp:rtcp-fb:0”
type=“ccm” subtype=“fir”/><rtcp-fb
xmlns=“urn:xmpp:jingle:apps:rtp:rtcp-fb:0” type=“nack”/><rtcp-fb
xmlns=“urn:xmpp:jingle:apps:rtp:rtcp-fb:0” type=“nack”
subtype=“pli”/><rtcp-fb xmlns=“urn:xmpp:jingle:apps:rtp:rtcp-fb:0”
type=“goog-remb”/><parameter value=“800”
name=“x-google-start-bitrate”/></payload-type><rtp-hdrext id=“3”
uri=“http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time”/></channel></content><content
name=“data”><sctpconnection channel-bundle-id=“3867d61a” port=“5000”
initiator=“true” endpoint=“3867d61a”/></content><channel-bundle
id=“3867d61a”><transport
xmlns=“urn:xmpp:jingle:transports:ice-udp:1”><fingerprint
xmlns=“urn:xmpp:jingle:apps:dtls:0”
required=“false”/></transport></channel-bundle></conference></iq>
JVB 2016-11-03 11:07:32.921 INFO: [170]
org.jitsi.videobridge.Conference.log() Created an ICE agent with local
ufrag 1ui81b0ktum5o for endpoint 3867d61a. Is initiator: true.
JVB 2016-11-03 11:07:32.925 INFO: [170]
org.jitsi.videobridge.xmpp.ComponentImpl.log() SENT: <iq
id=“4WKTW-373328”
to="focus@auth.jitsi.mydomainexample.com/focus161788377478645"
from=“jitsi-videobridge.jitsi.mydomainexample.com
type=“result”><conference xmlns=“http://jitsi.org/protocol/colibri
id=“78f2f5db865d8d9c” name=“tools”><content name=“audio”><channel
endpoint=“3867d61a” expire=“60” id=“6025ebf3a9f541dd” initiator=“true”
channel-bundle-id=“3867d61a” rtp-level-relay-type=“translator”><source
xmlns=“urn:xmpp:jingle:apps:rtp:ssma:0”
ssrc=“1795394142”></source></channel></content><content
name=“video”><channel endpoint=“3867d61a” expire=“60”
id=“972f64f7bf7ee051” initiator=“true” channel-bundle-id=“3867d61a”
last-n="-1" simulcast-mode=“REWRITING”
rtp-level-relay-type=“translator”><source
xmlns=“urn:xmpp:jingle:apps:rtp:ssma:0”
ssrc=“1037764043”></source></channel></content><content
name=“data”><sctpconnection endpoint=“3867d61a” expire=“60”
id=“75bbc964c4395be1” initiator=“true” channel-bundle-id=“3867d61a”
port=“5000”/></content><channel-bundle id=“0e3024cd”><transport
xmlns=“urn:xmpp:jingle:transports:ice-udp:1”
pwd=“40he0mgoini4r87p3lv4dsr5o3”
ufrag=“2qau41b0ktnvih”><rtcp-mux/><fingerprint
xmlns=“urn:xmpp:jingle:apps:dtls:0” hash=“sha-1”
setup=“active”>1A:1A:71:F5:C8:E8:A5:22:62:FE:50:F5:6C:2C:A9:0E:00:27:E7:EB</fingerprint><candidate
component=“1” foundation=“1” generation=“0”
id=“78f2f5db865d8d9c6c58e88c10725c98072864c64” network=“0”
priority=“2130706431” protocol=“ssltcp” tcptype=“passive” type=“host”
ip=“46.005.52.11” port=“4443”/><candidate component=“1” foundation=“2”
generation=“0” id=“78f2f5db865d8d9c6c58e88c10725c98072866219”
network=“0” priority=“2130706431” protocol=“udp” type=“host”
ip=“46.005.52.11”
port=“10000”/></transport></channel-bundle><channel-bundle
id=“e18ac58b”><transport xmlns=“urn:xmpp:jingle:transports:ice-udp:1”
pwd=“1kiot6n5ol62tusvh35nu1db7i”
ufrag=“e8nem1b0kthn3i”><rtcp-mux/><fingerprint
xmlns=“urn:xmpp:jingle:apps:dtls:0” hash=“sha-1”
setup=“active”>1A:1A:71:F5:C8:E8:A5:22:62:FE:50:F5:6C:2C:A9:0E:00:27:E7:EB</fingerprint><candidate
component=“1” foundation=“1” generation=“0”
id=“78f2f5db865d8d9c67cd6addf36f2680ffffffff8ecdd672” network=“0”
priority=“2130706431” protocol=“ssltcp” tcptype=“passive” type=“host”
ip=“46.005.52.11” port=“4443”/><candidate component=“1” foundation=“2”
generation=“0” id=“78f2f5db865d8d9c67cd6addf36f2680ffffffff8ecdec27”
network=“0” priority=“2130706431” protocol=“udp” type=“host”
ip=“46.005.52.11”
port=“10000”/></transport></channel-bundle><channel-bundle
id=“369e1556”><transport xmlns=“urn:xmpp:jingle:transports:ice-udp:1”
pwd=“3tivg6jscqcqu9hc92cuo9sr6k”
ufrag=“793sa1b0ktgjks”><rtcp-mux/><fingerprint
xmlns=“urn:xmpp:jingle:apps:dtls:0” hash=“sha-1”
setup=“actpass”>1A:1A:71:F5:C8:E8:A5:22:62:FE:50:F5:6C:2C:A9:0E:00:27:E7:EB</fingerprint><candidate
component=“1” foundation=“1” generation=“0”
id=“78f2f5db865d8d9c4bb5392659d53bd706cb51321” network=“0”
priority=“2130706431” protocol=“ssltcp” tcptype=“passive” type=“host”
ip=“46.005.52.11” port=“4443”/><candidate component=“1” foundation=“2”
generation=“0” id=“78f2f5db865d8d9c4bb5392659d53bd706cb528d6”
network=“0” priority=“2130706431” protocol=“udp” type=“host”
ip=“46.005.52.11”
port=“10000”/></transport></channel-bundle><channel-bundle
id=“3867d61a”><transport xmlns=“urn:xmpp:jingle:transports:ice-udp:1”
pwd=“2gehm6e4go3bvtqgssmq0kbcbr”
ufrag=“1ui81b0ktum5o”><rtcp-mux/><fingerprint
xmlns=“urn:xmpp:jingle:apps:dtls:0” hash=“sha-1”
setup=“actpass”>1A:1A:71:F5:C8:E8:A5:22:62:FE:50:F5:6C:2C:A9:0E:00:27:E7:EB</fingerprint><candidate
component=“1” foundation=“1” generation=“0”
id=“78f2f5db865d8d9c55c1d64e7bece5e60ffffffffac52e366” network=“0”
priority=“2130706431” protocol=“ssltcp” tcptype=“passive” type=“host”
ip=“46.005.52.11” port=“4443”/><candidate component=“1” foundation=“2”
generation=“0” id=“78f2f5db865d8d9c55c1d64e7bece5e60ffffffffac52f91b”
network=“0” priority=“2130706431” protocol=“udp” type=“host”
ip=“46.005.52.11”
port=“10000”/></transport></channel-bundle></conference></iq>
</pre>

n particular, looks more frequent for the authenticated user of the
meeting (https://github.com/jitsi/jicofo#secure-domain).

After the reading of this thread
(http://lists.jitsi.org/pipermail/dev/2015-June/024339.html), I'm
starting to suspect that the reason why some participants can not listen
anymore the others is because the some kind of inconsistence in the
resources associated to a MCU. In the linked post somebody comments this:

    specify the resource identifier for the jid, so everytime
    Prosody associates different resources. Having this one constant,
    Prosody will destroy the last session automatically
   
So, my question is, how can I try it. Any examples for prosody.cfg or
jitsi-meet?

···

--
Pablo Saavedra Rodiño
psaavedra@igalia.com | Mail
www.igalia.com | Web