[jitsi-dev] More on Rest


#1

Having made a lot of progress with Java and Javascript, I still don't
have a webrtc completed transaction, but I think I am quite close.

The message that I think causes it to fail at the moment is:

Jan 17, 2017 4:28:21 PM org.jitsi.util.LoggerImpl log
WARNING: Dropping a DTLS packet. This DtlsPacketTransformer has not been
started successfully or has been closed.

Question 1.

Does anyone have an idea as to what might cause that.

According to Chrome IceGatheringState is completed, but it has not gone
any further. If I navigate from the web page then connectionstate fails.

Hence it is in the middle of getting connected.

It drops the DTLS packet 8 seconds before ICEGathering is completed.

In the Chrome log "Binding Request timed out from [each of the three IP
addresses/ports for each channel bundle]

I am going to debug at the dropping the packet thingy, but any
suggestions would be welcome.


#2

I got into the debugger and found that datagramTransport was not initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

      if (rtcpmux && Component.RTCP == componentID)
         {
             // In the case of rtcp-mux, the RTCP transformer does not create
             // a DTLS session. The SRTP context (_srtpTransformer) will be
             // initialized on demand using initializeSRTCPTransformerFromRtp().
             return;
         }

I, therefore, took rtcp-mux out of the JSON and it crashes in a different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised- actually i will try false instead and see if that crashes).

···

On 17/01/2017 16:44, John Hemming wrote:

Having made a lot of progress with Java and Javascript, I still don't
have a webrtc completed transaction, but I think I am quite close.

The message that I think causes it to fail at the moment is:

Jan 17, 2017 4:28:21 PM org.jitsi.util.LoggerImpl log
WARNING: Dropping a DTLS packet. This DtlsPacketTransformer has not been
started successfully or has been closed.

Question 1.

Does anyone have an idea as to what might cause that.

According to Chrome IceGatheringState is completed, but it has not gone
any further. If I navigate from the web page then connectionstate fails.

Hence it is in the middle of getting connected.

It drops the DTLS packet 8 seconds before ICEGathering is completed.

In the Chrome log "Binding Request timed out from [each of the three IP
addresses/ports for each channel bundle]

I am going to debug at the dropping the packet thingy, but any
suggestions would be welcome.

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


#3

Actually that was not right. I tried to take rtcp-mux out and it ignored me and set it to true.

Hence I could definitely do with some hints as to whether it should be true or false.

···

On 17/01/2017 17:02, John Hemming wrote:

I got into the debugger and found that datagramTransport was not initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

     if (rtcpmux && Component.RTCP == componentID)
        {
            // In the case of rtcp-mux, the RTCP transformer does not create
            // a DTLS session. The SRTP context (_srtpTransformer) will be
            // initialized on demand using initializeSRTCPTransformerFromRtp().
            return;
        }

I, therefore, took rtcp-mux out of the JSON and it crashes in a different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised- actually i will try false instead and see if that crashes).

On 17/01/2017 16:44, John Hemming wrote:

Having made a lot of progress with Java and Javascript, I still don't
have a webrtc completed transaction, but I think I am quite close.

The message that I think causes it to fail at the moment is:

Jan 17, 2017 4:28:21 PM org.jitsi.util.LoggerImpl log
WARNING: Dropping a DTLS packet. This DtlsPacketTransformer has not been
started successfully or has been closed.

Question 1.

Does anyone have an idea as to what might cause that.

According to Chrome IceGatheringState is completed, but it has not gone
any further. If I navigate from the web page then connectionstate fails.

Hence it is in the middle of getting connected.

It drops the DTLS packet 8 seconds before ICEGathering is completed.

In the Chrome log "Binding Request timed out from [each of the three IP
addresses/ports for each channel bundle]

I am going to debug at the dropping the packet thingy, but any
suggestions would be welcome.

_______________________________________________
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


#4

Hi,

I got into the debugger and found that datagramTransport was not
initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

      if (rtcpmux && Component.RTCP == componentID)
         {
             // In the case of rtcp-mux, the RTCP transformer does not
create
             // a DTLS session. The SRTP context (_srtpTransformer) will be
             // initialized on demand using
initializeSRTCPTransformerFromRtp().
             return;
         }

I, therefore, took rtcp-mux out of the JSON and it crashes in a
different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised-
actually i will try false instead and see if that crashes).

The bridge should support these two modes:
1. rtcp-mux + bundle
2. no rtcp-mux and no bundle.

Nowadays the first one is most often used, especially with browsers, so I recommend using it. If you want to go with the second you would need to make sure that you pass the properly modified SDP to the browser, and that the bridge is allowed to allocate ports dynamically.

Boris

···

On 17/01/2017 11:02, John Hemming wrote:


#5

Looking at this though:

         if (rtcpmux && Component.RTCP == componentID)
         {
             // This should never happen.
             logger.warn(
                     "Dropping a DTLS packet, because it was received on the"
                         + " RTCP channel while rtcpmux is in use.");
             return;
         }

The conditions that would in theory rely on

initializeSRTCPTransformerFromRtp().

Are not supposed to happen.

···

On 17/01/2017 17:17, John Hemming wrote:

Actually that was not right. I tried to take rtcp-mux out and it ignored me and set it to true.

Hence I could definitely do with some hints as to whether it should be true or false.

On 17/01/2017 17:02, John Hemming wrote:

I got into the debugger and found that datagramTransport was not initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

     if (rtcpmux && Component.RTCP == componentID)
        {
            // In the case of rtcp-mux, the RTCP transformer does not create
            // a DTLS session. The SRTP context (_srtpTransformer) will be
            // initialized on demand using initializeSRTCPTransformerFromRtp().
            return;
        }

I, therefore, took rtcp-mux out of the JSON and it crashes in a different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised- actually i will try false instead and see if that crashes).

On 17/01/2017 16:44, John Hemming wrote:

Having made a lot of progress with Java and Javascript, I still don't
have a webrtc completed transaction, but I think I am quite close.

The message that I think causes it to fail at the moment is:

Jan 17, 2017 4:28:21 PM org.jitsi.util.LoggerImpl log
WARNING: Dropping a DTLS packet. This DtlsPacketTransformer has not been
started successfully or has been closed.

Question 1.

Does anyone have an idea as to what might cause that.

According to Chrome IceGatheringState is completed, but it has not gone
any further. If I navigate from the web page then connectionstate fails.

Hence it is in the middle of getting connected.

It drops the DTLS packet 8 seconds before ICEGathering is completed.

In the Chrome log "Binding Request timed out from [each of the three IP
addresses/ports for each channel bundle]

I am going to debug at the dropping the packet thingy, but any
suggestions would be welcome.

_______________________________________________
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

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


#6

Thank you for this. I based the SDP on the one in Ofmeet which AIUI is a 2014 cut of the bridge. That has separate DTLS entries and candidates for each of video, data and audio.

I think it is correctly configured for a single channel-bundle for each of the channels.

However, I will reconfigure it to put video, audio and data into a single channel bundle.

Just to make sure I understand this. Does this mean that all three channels are multiplexed into one communication. That communication will be with a single port rather than three at the moment. I should configure the SDP to have a session fingerprint and fragment etc (the DTLS stuff) and the candidates should also be at the session level.

···

On 18/01/2017 03:19, Boris Grozev wrote:

Hi,

On 17/01/2017 11:02, John Hemming wrote:

I got into the debugger and found that datagramTransport was not
initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

      if (rtcpmux && Component.RTCP == componentID)
         {
             // In the case of rtcp-mux, the RTCP transformer does not
create
             // a DTLS session. The SRTP context (_srtpTransformer) will be
             // initialized on demand using
initializeSRTCPTransformerFromRtp().
             return;
         }

I, therefore, took rtcp-mux out of the JSON and it crashes in a
different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised-
actually i will try false instead and see if that crashes).

The bridge should support these two modes:
1. rtcp-mux + bundle
2. no rtcp-mux and no bundle.

Nowadays the first one is most often used, especially with browsers, so I recommend using it. If you want to go with the second you would need to make sure that you pass the properly modified SDP to the browser, and that the bridge is allowed to allocate ports dynamically.

Boris

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


#7

I think this is the correct RFC

https://tools.ietf.org/html/rfc5761

···

On 18/01/2017 06:58, John Hemming wrote:

Thank you for this. I based the SDP on the one in Ofmeet which AIUI is a 2014 cut of the bridge. That has separate DTLS entries and candidates for each of video, data and audio.

I think it is correctly configured for a single channel-bundle for each of the channels.

However, I will reconfigure it to put video, audio and data into a single channel bundle.

Just to make sure I understand this. Does this mean that all three channels are multiplexed into one communication. That communication will be with a single port rather than three at the moment. I should configure the SDP to have a session fingerprint and fragment etc (the DTLS stuff) and the candidates should also be at the session level.

On 18/01/2017 03:19, Boris Grozev wrote:

Hi,

On 17/01/2017 11:02, John Hemming wrote:

I got into the debugger and found that datagramTransport was not
initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

      if (rtcpmux && Component.RTCP == componentID)
         {
             // In the case of rtcp-mux, the RTCP transformer does not
create
             // a DTLS session. The SRTP context (_srtpTransformer) will be
             // initialized on demand using
initializeSRTCPTransformerFromRtp().
             return;
         }

I, therefore, took rtcp-mux out of the JSON and it crashes in a
different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised-
actually i will try false instead and see if that crashes).

The bridge should support these two modes:
1. rtcp-mux + bundle
2. no rtcp-mux and no bundle.

Nowadays the first one is most often used, especially with browsers, so I recommend using it. If you want to go with the second you would need to make sure that you pass the properly modified SDP to the browser, and that the bridge is allowed to allocate ports dynamically.

Boris

_______________________________________________
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


#8

Thank you for this. I based the SDP on the one in Ofmeet which AIUI is a
2014 cut of the bridge. That has separate DTLS entries and candidates for
each of video, data and audio.

This is very old client and bridge and everything significantly
changed since then. It is even in the state where there is no jicofo
and the focus is in one of the clients. So my advice is upgrading
everything, and don't try to fix stuff that we had already worked on
for more than 2 years.
Just my 2 cents.

···

On Wed, Jan 18, 2017 at 12:58 AM, John Hemming <john@hemming.email> wrote:

I think it is correctly configured for a single channel-bundle for each of
the channels.

However, I will reconfigure it to put video, audio and data into a single
channel bundle.

Just to make sure I understand this. Does this mean that all three
channels are multiplexed into one communication. That communication will
be with a single port rather than three at the moment. I should configure
the SDP to have a session fingerprint and fragment etc (the DTLS stuff) and
the candidates should also be at the session level.

On 18/01/2017 03:19, Boris Grozev wrote:

Hi,

On 17/01/2017 11:02, John Hemming wrote:

I got into the debugger and found that datagramTransport was not
initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

      if (rtcpmux && Component.RTCP == componentID)
         {
             // In the case of rtcp-mux, the RTCP transformer does not
create
             // a DTLS session. The SRTP context (_srtpTransformer) will
be
             // initialized on demand using
initializeSRTCPTransformerFromRtp().
             return;
         }

I, therefore, took rtcp-mux out of the JSON and it crashes in a
different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised-
actually i will try false instead and see if that crashes).

The bridge should support these two modes:
1. rtcp-mux + bundle
2. no rtcp-mux and no bundle.

Nowadays the first one is most often used, especially with browsers, so I
recommend using it. If you want to go with the second you would need to make
sure that you pass the properly modified SDP to the browser, and that the
bridge is allowed to allocate ports dynamically.

Boris

_______________________________________________
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


#9

Thank you for this. I based the SDP on the one in Ofmeet which AIUI is
a 2014 cut of the bridge. That has separate DTLS entries and candidates
for each of video, data and audio.

I think it is correctly configured for a single channel-bundle for each
of the channels.

However, I will reconfigure it to put video, audio and data into a
single channel bundle.

Just to make sure I understand this. Does this mean that all three
channels are multiplexed into one communication. That communication
will be with a single port rather than three at the moment.

Correct.

I should
configure the SDP to have a session fingerprint and fragment etc (the
DTLS stuff) and the candidates should also be at the session level.

I don't think candidates should go to the session level (because e.g. you could have more than one bundle). You can look at SDP from current versions of jitsi-meet (e.g. https://meet.jit.si) for examples.

Regards,
Boris

···

On 18/01/2017 00:58, John Hemming wrote:


#10

Thank you for this. However, I cannot run jitsi meet as I run on Windows and Prosody does not like that.

I will try again using only the candidates from the channel bundle. I had used the ones from the conference.

It would be really helpful to see a valid SDP for a current version of the bridge if anyone can help with this.

···

On 18/01/2017 16:30, Boris Grozev wrote:

On 18/01/2017 00:58, John Hemming wrote:

Thank you for this. I based the SDP on the one in Ofmeet which AIUI is
a 2014 cut of the bridge. That has separate DTLS entries and candidates
for each of video, data and audio.

I think it is correctly configured for a single channel-bundle for each
of the channels.

However, I will reconfigure it to put video, audio and data into a
single channel bundle.

Just to make sure I understand this. Does this mean that all three
channels are multiplexed into one communication. That communication
will be with a single port rather than three at the moment.

Correct.

I should
configure the SDP to have a session fingerprint and fragment etc (the
DTLS stuff) and the candidates should also be at the session level.

I don't think candidates should go to the session level (because e.g. you could have more than one bundle). You can look at SDP from current versions of jitsi-meet (e.g. https://meet.jit.si) for examples.

Regards,
Boris


#11

I am not trying to fix the bridge. I am trying to work out why my code is not working (probably something to do with the SDP).

Can someone send me an SDP that works?

(or the list).

···

On 18/01/2017 14:59, Damian Minkov wrote:

On Wed, Jan 18, 2017 at 12:58 AM, John Hemming <john@hemming.email> wrote:

Thank you for this. I based the SDP on the one in Ofmeet which AIUI is a
2014 cut of the bridge. That has separate DTLS entries and candidates for
each of video, data and audio.

This is very old client and bridge and everything significantly
changed since then. It is even in the state where there is no jicofo
and the focus is in one of the clients. So my advice is upgrading
everything, and don't try to fix stuff that we had already worked on
for more than 2 years.
Just my 2 cents.

I think it is correctly configured for a single channel-bundle for each of
the channels.

However, I will reconfigure it to put video, audio and data into a single
channel bundle.

Just to make sure I understand this. Does this mean that all three
channels are multiplexed into one communication. That communication will
be with a single port rather than three at the moment. I should configure
the SDP to have a session fingerprint and fragment etc (the DTLS stuff) and
the candidates should also be at the session level.

On 18/01/2017 03:19, Boris Grozev wrote:

Hi,

On 17/01/2017 11:02, John Hemming wrote:

I got into the debugger and found that datagramTransport was not
initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

       if (rtcpmux && Component.RTCP == componentID)
          {
              // In the case of rtcp-mux, the RTCP transformer does not
create
              // a DTLS session. The SRTP context (_srtpTransformer) will
be
              // initialized on demand using
initializeSRTCPTransformerFromRtp().
              return;
          }

I, therefore, took rtcp-mux out of the JSON and it crashes in a
different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised-
actually i will try false instead and see if that crashes).

The bridge should support these two modes:
1. rtcp-mux + bundle
2. no rtcp-mux and no bundle.

Nowadays the first one is most often used, especially with browsers, so I
recommend using it. If you want to go with the second you would need to make
sure that you pass the properly modified SDP to the browser, and that the
bridge is allowed to allocate ports dynamically.

Boris

_______________________________________________
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

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


#12

Hi,

Just open two tabs on meet.jit.si and in one of them open the
javascript console and execute 'APP.conference.saveLogs();'. This will
produce a json file with all the communication between the client and
the server, including the SDPs.

Regards
damencho

···

On Wed, Jan 18, 2017 at 3:57 PM, John Hemming <john@hemming.email> wrote:

I am not trying to fix the bridge. I am trying to work out why my code is
not working (probably something to do with the SDP).

Can someone send me an SDP that works?

(or the list).

On 18/01/2017 14:59, Damian Minkov wrote:

On Wed, Jan 18, 2017 at 12:58 AM, John Hemming <john@hemming.email> wrote:

Thank you for this. I based the SDP on the one in Ofmeet which AIUI is a
2014 cut of the bridge. That has separate DTLS entries and candidates
for
each of video, data and audio.

This is very old client and bridge and everything significantly
changed since then. It is even in the state where there is no jicofo
and the focus is in one of the clients. So my advice is upgrading
everything, and don't try to fix stuff that we had already worked on
for more than 2 years.
Just my 2 cents.

I think it is correctly configured for a single channel-bundle for each
of
the channels.

However, I will reconfigure it to put video, audio and data into a single
channel bundle.

Just to make sure I understand this. Does this mean that all three
channels are multiplexed into one communication. That communication
will
be with a single port rather than three at the moment. I should
configure
the SDP to have a session fingerprint and fragment etc (the DTLS stuff)
and
the candidates should also be at the session level.

On 18/01/2017 03:19, Boris Grozev wrote:

Hi,

On 17/01/2017 11:02, John Hemming wrote:

I got into the debugger and found that datagramTransport was not
initialised in DtlsPacketTransformer

I looked at start and found that it is a design feature viz:

       if (rtcpmux && Component.RTCP == componentID)
          {
              // In the case of rtcp-mux, the RTCP transformer does not
create
              // a DTLS session. The SRTP context (_srtpTransformer)
will
be
              // initialized on demand using
initializeSRTCPTransformerFromRtp().
              return;
          }

I, therefore, took rtcp-mux out of the JSON and it crashes in a
different way.

Question:

Should it work for both rtcp-mux =true and rtcp-mux (not initialised-
actually i will try false instead and see if that crashes).

The bridge should support these two modes:
1. rtcp-mux + bundle
2. no rtcp-mux and no bundle.

Nowadays the first one is most often used, especially with browsers, so
I
recommend using it. If you want to go with the second you would need to
make
sure that you pass the properly modified SDP to the browser, and that
the
bridge is allowed to allocate ports dynamically.

Boris

_______________________________________________
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

_______________________________________________
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


#13

You can use a public deployment of jitsi-meet (https://meet.jit.si) and see the SDPs in chrome://webrtc-internals

Boris

···

On 18/01/2017 15:54, John Hemming wrote:

Thank you for this. However, I cannot run jitsi meet as I run on
Windows and Prosody does not like that.

I will try again using only the candidates from the channel bundle. I
had used the ones from the conference.

It would be really helpful to see a valid SDP for a current version of
the bridge if anyone can help with this.


#14

Thank you for this. (copying an extract from web-rtc internals)

19/01/2017, 07:26:25 iceGatheringStateChange
19/01/2017, 07:26:27 iceConnectionStateChange

ICEConnectionStateConnected

I note that the candidates are re-ordered slightly in jitsi-meet from the sequence they arrive in the JSON. I did not re-order them and it still connected.

Is there potentially an issue there?

···

On 18/01/2017 22:46, Boris Grozev wrote:

On 18/01/2017 15:54, John Hemming wrote:

Thank you for this. However, I cannot run jitsi meet as I run on
Windows and Prosody does not like that.

I will try again using only the candidates from the channel bundle. I
had used the ones from the conference.

It would be really helpful to see a valid SDP for a current version of
the bridge if anyone can help with this.

You can use a public deployment of jitsi-meet (https://meet.jit.si) and see the SDPs in chrome://webrtc-internals

Boris