[jitsi-dev] DtlsPacketTransformer and rtcp-mux


#1

I'm attempting to use rtcp-mux for audio and video streams and I'm getting
this error in my logs:
[org.jitsi.impl.neomedia.RTPConnectorInputStream.receiveThread] WARN
o.j.i.n.t.d.DtlsPacketTransformer - Dropping a DTLS record, because it was
received on the RTCP channel while rtcpmux is in use.

I've set rtcp-mux everywhere that I can find that its supported, so what am
I missing?
Some code sections where its set, not in any kind of order here:
StreamConnector audioConnector = new DefaultStreamConnector(rtpSocket,
rtcpSocket, rtcpMux);
audioMediaStream.setConnector(audioConnector);

and my media stream target uses the rtpPair for its rtcpPair since I see no
other way to indicate that the muxing is in use:
MediaStreamTarget mediaStreamTarget = new
MediaStreamTarget(rtpPair.getRemoteCandidate().getTransportAddress(),
rtpPair.getRemoteCandidate().getTransportAddress());

I checked github libjitsi HEAD and heres the "funny" note in the code:
https://github.com/jitsi/libjitsi/blob/73f20dc7f35b19914d8c7181d50826a6e404be08/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L677

Paul


#2

[...]

are you talking to chrome and your remotedescription is an answer?
If yes: Chrome is behaving in ... strange ways when it is the controlling agent.

···

Am 08.02.2016 um 17:32 schrieb Mondain:

I'm attempting to use rtcp-mux for audio and video streams and I'm getting
this error in my logs:


#3

I'm attempting to use rtcp-mux for audio and video streams and I'm
getting this error in my logs:
[org.jitsi.impl.neomedia.RTPConnectorInputStream.receiveThread] WARN
  o.j.i.n.t.d.DtlsPacketTransformer - Dropping a DTLS record, because it
was received on the RTCP channel while rtcpmux is in use.

I've set rtcp-mux everywhere that I can find that its supported, so what
am I missing?

Libjitsi doesn't natively support rtcp-mux. It expects its data input stream to only read RTP packets, and its control input stream to only read RTCP packets. To achieve this, you can use ice4j's MultiplexingDatagramSocket (or MultiplexingSocket) classes to create DatagramSocket (or Socket) instances which read only a subset of the packets in the original instance. E.g. from the selected CandidatePair you can get a MultiplexingDatagramSocket, and from that you can get two DatagramSocket instances (one for RTP and one for RTCP) using getSocket() with an appropriate DatagramPacketFilter. Something like this:

CandidatePair pair;
MultiplexingDatagramSocket mainSocket = (MultiplexingDatagramSocket) pair.getIceSocketWrapper().getUDPSocket();

DatagramSocket rtpSocket = mainSocket.getSocket(new RTPFilter());
DatagramSocket rtcpSocket = mainSocket.getSocket(new RTCPFilter());

StreamConnector = new DefaultStreamConnector(rtpSocket, rtcpSocket, true);

Where RTPFilter and RTCPFilter are your own implementations (it makes sense to include these as part of either ice4j or libjitsi, but we don't have them; contributions would be welcome). You can probably base these on RtpChannelDatagramFilter.

The DTLS code in libjitsi is an exception in that it is somewhat aware of rtcp-mux. You need to:
1. Tell it that you want rtcp-mux (DtlsControl#setRtcpmux)
2. Include DTLS packets in the data stream (i.e. in RTPFilter)
3. Not include DTLS packets in the control stream, in order to avoid the warning that you see (in RTCPFilter).

We do something similar in videobridge[0,1], but it is somewhat messy because we also juggle multiple Channels and SCTP ("bundle").

Some code sections where its set, not in any kind of order here:
StreamConnector audioConnector = new DefaultStreamConnector(rtpSocket,
rtcpSocket, rtcpMux);
audioMediaStream.setConnector(audioConnector);

and my media stream target uses the rtpPair for its rtcpPair since I see
no other way to indicate that the muxing is in use:

This seems right.

MediaStreamTarget mediaStreamTarget = new
MediaStreamTarget(rtpPair.getRemoteCandidate().getTransportAddress(),
rtpPair.getRemoteCandidate().getTransportAddress());

I checked github libjitsi HEAD and heres the "funny" note in the code:
https://github.com/jitsi/libjitsi/blob/73f20dc7f35b19914d8c7181d50826a6e404be08/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L677

Paul

Regards,
Boris

[0] https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L1328
[1] https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L1528

···

On 08/02/16 19:32, Mondain wrote:

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


#4

Yes, Phillip, I'm using Chrome. Boris, thank you for the extra level of
detail, much appreciated.

Paul

···

On Tue, Feb 9, 2016 at 3:00 AM Boris Grozev <boris@jitsi.org> wrote:

On 08/02/16 19:32, Mondain wrote:
> I'm attempting to use rtcp-mux for audio and video streams and I'm
> getting this error in my logs:
> [org.jitsi.impl.neomedia.RTPConnectorInputStream.receiveThread] WARN
> o.j.i.n.t.d.DtlsPacketTransformer - Dropping a DTLS record, because it
> was received on the RTCP channel while rtcpmux is in use.
>
> I've set rtcp-mux everywhere that I can find that its supported, so what
> am I missing?

Libjitsi doesn't natively support rtcp-mux. It expects its data input
stream to only read RTP packets, and its control input stream to only
read RTCP packets. To achieve this, you can use ice4j's
MultiplexingDatagramSocket (or MultiplexingSocket) classes to create
DatagramSocket (or Socket) instances which read only a subset of the
packets in the original instance. E.g. from the selected CandidatePair
you can get a MultiplexingDatagramSocket, and from that you can get two
DatagramSocket instances (one for RTP and one for RTCP) using
getSocket() with an appropriate DatagramPacketFilter. Something like this:

CandidatePair pair;
MultiplexingDatagramSocket mainSocket = (MultiplexingDatagramSocket)
pair.getIceSocketWrapper().getUDPSocket();

DatagramSocket rtpSocket = mainSocket.getSocket(new RTPFilter());
DatagramSocket rtcpSocket = mainSocket.getSocket(new RTCPFilter());

StreamConnector = new DefaultStreamConnector(rtpSocket, rtcpSocket, true);

Where RTPFilter and RTCPFilter are your own implementations (it makes
sense to include these as part of either ice4j or libjitsi, but we don't
have them; contributions would be welcome). You can probably base these
on RtpChannelDatagramFilter.

The DTLS code in libjitsi is an exception in that it is somewhat aware
of rtcp-mux. You need to:
1. Tell it that you want rtcp-mux (DtlsControl#setRtcpmux)
2. Include DTLS packets in the data stream (i.e. in RTPFilter)
3. Not include DTLS packets in the control stream, in order to avoid the
warning that you see (in RTCPFilter).

We do something similar in videobridge[0,1], but it is somewhat messy
because we also juggle multiple Channels and SCTP ("bundle").

> Some code sections where its set, not in any kind of order here:
> StreamConnector audioConnector = new DefaultStreamConnector(rtpSocket,
> rtcpSocket, rtcpMux);
> audioMediaStream.setConnector(audioConnector);
>
> and my media stream target uses the rtpPair for its rtcpPair since I see
> no other way to indicate that the muxing is in use:

This seems right.

> MediaStreamTarget mediaStreamTarget = new
> MediaStreamTarget(rtpPair.getRemoteCandidate().getTransportAddress(),
> rtpPair.getRemoteCandidate().getTransportAddress());
>
> I checked github libjitsi HEAD and heres the "funny" note in the code:
>
https://github.com/jitsi/libjitsi/blob/73f20dc7f35b19914d8c7181d50826a6e404be08/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L677
>
> Paul

Regards,
Boris

[0]

https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L1328
[1]

https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L1528
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

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