[jitsi-dev] Implementation of voice codecs and respective bitrates on Jitsi


#1

Hello Devs of Jitsi!

I have been using Jitsi for the past day or so and it has been a great
experience, thank for your work on this open-source project.

I have a few questions on how some of the supported voice codecs are being
implemented.

- In regards to the PCM (u-law and a-law) codecs, are their bit-rates
static at 64kbps?
- Is the GSM codec considered to be GSM_EFR (Enhanced full rate) with a
bit-rate of 12.2kbps?
- Is the WB-AMR codec being implemented similarly to 3GPP with three
configurations and varying bit-rates? Is there a way to control this on the
user side if so?

I tried going through github and the source code but I couldn't find the
answers to my questions. I hope these questions are coherent and not overly
complicated. I look forward to hearing back, thank you for your help.

Best Regards,
Thomas Rigolage


#2

Hi Thomas,

I only have an answer for your first question: yes, PCMA and PCMU have a constant bitrate of 64kbps. Hopefully someone else can help with the other questions.

Nowadays for most scenarios it makes little sense to use anything but opus.

Regards,
Boris

···

On 26/01/2018 10:42, Thomas Rigolage wrote:

Hello Devs of Jitsi!

I have been using Jitsi for the past day or so and it has been a great experience, thank for your work on this open-source project.

I have a few questions on how some of the supported voice codecs are being implemented.

- In regards to the PCM (u-law and a-law) codecs, are their bit-rates static at 64kbps?
- Is the GSM codec considered to be GSM_EFR (Enhanced full rate) with a bit-rate of 12.2kbps?
- Is the WB-AMR codec being implemented similarly to 3GPP with three configurations and varying bit-rates? Is there a way to control this on the user side if so?

I tried going through github and the source code but I couldn't find the answers to my questions. I hope these questions are coherent and not overly complicated. I look forward to hearing back, thank you for your help.

Best Regards,
Thomas Rigolage

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


#3

I am using software based upon the bridge on a number of windows devices. It has recently started crashing the JVM on my development machine when I start doing a few things. I have it on two other machines and it has not crashed on either of these.

a) I cannot find any log files which show why it is crashing. Does anyone have any suggestions as to how to get a log file for a JVM crash. I have tried looking for hs_err*.log and specifying a value for -XX:ErrorFile I am running the java command to do this.

b) I am thinking that the main difference about my development machine is that I have applied Microsoft's patches for Spectre/Meltdown (I am not sure what patches, but some recent ones).

This log is normally just before the crash:
JVB 2018-01-24 10:28:16.493 INFO: [510] org.jitsi.videobridge.SctpConnection.log() CAT=stat sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec notification=SCTP_ASSOC_CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

Does anyone have any hints as to where to look for this?

I wonder if other people have had problems following updating for Meltdown/Spectre.

I have some other Microsoft updates pending, but am not enthusiastic about applying them. I probably will, but I am very tempted to go through the linux learning curve to get away from Windows.


#4

Hi Boris,

Thank you for the confirmation, I was hoping it was configured this way.

Also - I have answered my own question for #2 (confirmed it was GSM_FR, not
EFR using Wireshark).

I believe I am good, we could consider this thread closed. I appreciate the
help!

Best Regards,
Thomas Rigolage

···

On Fri, Jan 26, 2018 at 1:36 PM, Boris Grozev <boris@jitsi.org> wrote:

Hi Thomas,

I only have an answer for your first question: yes, PCMA and PCMU have a
constant bitrate of 64kbps. Hopefully someone else can help with the other
questions.

Nowadays for most scenarios it makes little sense to use anything but opus.

Regards,
Boris

On 26/01/2018 10:42, Thomas Rigolage wrote:

Hello Devs of Jitsi!

I have been using Jitsi for the past day or so and it has been a great
experience, thank for your work on this open-source project.

I have a few questions on how some of the supported voice codecs are
being implemented.

- In regards to the PCM (u-law and a-law) codecs, are their bit-rates
static at 64kbps?
- Is the GSM codec considered to be GSM_EFR (Enhanced full rate) with a
bit-rate of 12.2kbps?
- Is the WB-AMR codec being implemented similarly to 3GPP with three
configurations and varying bit-rates? Is there a way to control this on the
user side if so?

I tried going through github and the source code but I couldn't find the
answers to my questions. I hope these questions are coherent and not overly
complicated. I look forward to hearing back, thank you for your help.

Best Regards,
Thomas Rigolage

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


#5

I have made a bit of progress on this.

I discovered it was first a problem in ntdll.dll then I updated windows and it was a problem with jvm.dll then I updated the java runtime to 162 and it still crashed.

Then after a bit of rummaging I stopped it running the native method usrsctp_close which is linked to jnsctp.dll

 static void closeSocket\(long ptr\)
 \{
     logger\.info\(Utils\.getLogStart\(null\)\+&quot; native close of sctp socket&quot;\);
     if \(Status\.dontCloseUsrSCTPSocketsForNow==false\) \{
     usrsctp\_close\(ptr\);
     \}

     sockets\.remove\(Long\.valueOf\(ptr\)\);
 \}

As far as I can tell the JVM is no longer crashing. Interestingly it appears that it crashed about 4-5 seconds after uscrsctp_close was called.

Does anyone have any idea as to what this might be? Perhaps jnsctp needs updating in some way because of the windows updates.
Maybe the pointers are now wrong because of the windows updates.

···

On 26/01/2018 18:11, John Hemming wrote:

I am using software based upon the bridge on a number of windows devices. It has recently started crashing the JVM on my development machine when I start doing a few things. I have it on two other machines and it has not crashed on either of these.

a) I cannot find any log files which show why it is crashing. Does anyone have any suggestions as to how to get a log file for a JVM crash. I have tried looking for hs_err*.log and specifying a value for -XX:ErrorFile I am running the java command to do this.

b) I am thinking that the main difference about my development machine is that I have applied Microsoft's patches for Spectre/Meltdown (I am not sure what patches, but some recent ones).

This log is normally just before the crash:
JVB 2018-01-24 10:28:16.493 INFO: [510] org.jitsi.videobridge.SctpConnection.log() CAT=stat sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec notification=SCTP_ASSOC_CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

Does anyone have any hints as to where to look for this?

I wonder if other people have had problems following updating for Meltdown/Spectre.

I have some other Microsoft updates pending, but am not enthusiastic about applying them. I probably will, but I am very tempted to go through the linux learning curve to get away from Windows.

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

--

john.hemming.name <http://john.hemming.name>


#6

I thought I would see if I could find a better solution than just not closing scpt sockets. I think jnscpt.dll is based upon usrscpt (please correct me if I am wrong). I tried using usrscpt_shutdown, that failed with a link error so I looked at the dll and not all of the usrscpt functions are exported.

Can anyone please tell me where I might find the code for creating jnscpt.dll so that I might be able to export the shutdown function as well.

I assume that because scpt is included in linux this is not a linux issue. (or if it is then it has been solved as part of linux rather than usrscpt or anything like that).

However, for now I have reverted to not closing the sockets.

···

On 30/01/2018 15:07, John Hemming wrote:

I have made a bit of progress on this.

I discovered it was first a problem in ntdll.dll then I updated windows and it was a problem with jvm.dll then I updated the java runtime to 162 and it still crashed.

Then after a bit of rummaging I stopped it running the native method usrsctp_close which is linked to jnsctp.dll

static void closeSocket\(long ptr\)
\{
    logger\.info\(Utils\.getLogStart\(null\)\+&quot; native close of sctp socket&quot;\);
    if \(Status\.dontCloseUsrSCTPSocketsForNow==false\) \{
    usrsctp\_close\(ptr\);
    \}

    sockets\.remove\(Long\.valueOf\(ptr\)\);
\}

As far as I can tell the JVM is no longer crashing. Interestingly it appears that it crashed about 4-5 seconds after uscrsctp_close was called.

Does anyone have any idea as to what this might be? Perhaps jnsctp needs updating in some way because of the windows updates.
Maybe the pointers are now wrong because of the windows updates.

On 26/01/2018 18:11, John Hemming wrote:

I am using software based upon the bridge on a number of windows devices. It has recently started crashing the JVM on my development machine when I start doing a few things. I have it on two other machines and it has not crashed on either of these.

a) I cannot find any log files which show why it is crashing. Does anyone have any suggestions as to how to get a log file for a JVM crash. I have tried looking for hs_err*.log and specifying a value for -XX:ErrorFile I am running the java command to do this.

b) I am thinking that the main difference about my development machine is that I have applied Microsoft's patches for Spectre/Meltdown (I am not sure what patches, but some recent ones).

This log is normally just before the crash:
JVB 2018-01-24 10:28:16.493 INFO: [510] org.jitsi.videobridge.SctpConnection.log() CAT=stat sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec notification=SCTP_ASSOC_CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

Does anyone have any hints as to where to look for this?

I wonder if other people have had problems following updating for Meltdown/Spectre.

I have some other Microsoft updates pending, but am not enthusiastic about applying them. I probably will, but I am very tempted to go through the linux learning curve to get away from Windows.

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

--

john.hemming.name <http://john.hemming.name>

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

--

john.hemming.name <http://john.hemming.name>


#7

Hi,


There are few readme files there, explaining the building process.

Regards
damencho

···

On Jan 31, 2018 04:03, "John Hemming" <john@hemming.email> wrote:

I thought I would see if I could find a better solution than just not
closing scpt sockets. I think jnscpt.dll is based upon usrscpt (please
correct me if I am wrong). I tried using usrscpt_shutdown, that failed
with a link error so I looked at the dll and not all of the usrscpt
functions are exported.

Can anyone please tell me where I might find the code for creating
jnscpt.dll so that I might be able to export the shutdown function as well.

I assume that because scpt is included in linux this is not a linux
issue. (or if it is then it has been solved as part of linux rather than
usrscpt or anything like that).

However, for now I have reverted to not closing the sockets.

On 30/01/2018 15:07, John Hemming wrote:

I have made a bit of progress on this.

I discovered it was first a problem in ntdll.dll then I updated windows
and it was a problem with jvm.dll then I updated the java runtime to 162
and it still crashed.

Then after a bit of rummaging I stopped it running the native method
usrsctp_close which is linked to jnsctp.dll

    static void closeSocket(long ptr)
    {
        logger.info(Utils.getLogStart(null)+" native close of sctp
socket");
        if (Status.dontCloseUsrSCTPSocketsForNow==false) {
        usrsctp_close(ptr);
        }

        sockets.remove(Long.valueOf(ptr));
    }

As far as I can tell the JVM is no longer crashing. Interestingly it
appears that it crashed about 4-5 seconds after uscrsctp_close was called.

Does anyone have any idea as to what this might be? Perhaps jnsctp needs
updating in some way because of the windows updates.
Maybe the pointers are now wrong because of the windows updates.

On 26/01/2018 18:11, John Hemming wrote:

I am using software based upon the bridge on a number of windows devices.
It has recently started crashing the JVM on my development machine when I
start doing a few things. I have it on two other machines and it has not
crashed on either of these.

a) I cannot find any log files which show why it is crashing. Does anyone
have any suggestions as to how to get a log file for a JVM crash. I have
tried looking for hs_err*.log and specifying a value for -XX:ErrorFile
I am running the java command to do this.

b) I am thinking that the main difference about my development machine is
that I have applied Microsoft's patches for Spectre/Meltdown (I am not sure
what patches, but some recent ones).

This log is normally just before the crash:
JVB 2018-01-24 10:28:16.493 INFO: [510] org.jitsi.videobridge.SctpConnection.log()
CAT=stat sctp_notification,conf_id=30c6de8c34ec3069,content=data,
ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec notification=SCTP_ASSOC_
CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

Does anyone have any hints as to where to look for this?

I wonder if other people have had problems following updating for
Meltdown/Spectre.

I have some other Microsoft updates pending, but am not enthusiastic about
applying them. I probably will, but I am very tempted to go through the
linux learning curve to get away from Windows.

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

--

john.hemming.name

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

--

john.hemming.name

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


#8

Thank you for this. It appears to give quite good instructions on how to build an so library which I assume is for linux. However, I need to build a DLL library for Windows64. I have not done any C or C++ coding for 20 years plus, but have downloaded and installed visual studio 2017 and managed to build a usrsctp.dll file. I have also installed the C and H(eader) files which I presume do the JNI magic.

Is there anything anywhere that you can suggest that makes the next steps clearer. As it is a standard sort of thing I presume it should be quite easy to resolve, but a pointer would be nice. (much that it is a pointer that appears to be causing the problem).

···

On 31/01/2018 14:46, Damian Minkov wrote:

Hi,

https://github.com/jitsi/libjitsi/tree/master/src/native/sctp
There are few readme files there, explaining the building process.

Regards
damencho

On Jan 31, 2018 04:03, "John Hemming" <john@hemming.email> wrote:

    I thought I would see if I could find a better solution than just
    not closing scpt sockets. I think jnscpt.dll is based upon
    usrscpt (please correct me if I am wrong). I tried using
    usrscpt_shutdown, that failed with a link error so I looked at the
    dll and not all of the usrscpt functions are exported.

    Can anyone please tell me where I might find the code for creating
    jnscpt.dll so that I might be able to export the shutdown function
    as well.

    I assume that because scpt is included in linux this is not a
    linux issue. (or if it is then it has been solved as part of
    linux rather than usrscpt or anything like that).

    However, for now I have reverted to not closing the sockets.

    On 30/01/2018 15:07, John Hemming wrote:

    I have made a bit of progress on this.

    I discovered it was first a problem in ntdll.dll then I updated
    windows and it was a problem with jvm.dll then I updated the java
    runtime to 162 and it still crashed.

    Then after a bit of rummaging I stopped it running the native
    method usrsctp_close which is linked to jnsctp.dll

     static void closeSocket(long ptr)
     {
    logger.info <http://logger.info>(Utils.getLogStart(null)+" native
    close of sctp socket");
     if (Status.dontCloseUsrSCTPSocketsForNow==false) {
     usrsctp_close(ptr);
     }

     sockets.remove(Long.valueOf(ptr));
     }

    As far as I can tell the JVM is no longer crashing. Interestingly
    it appears that it crashed about 4-5 seconds after uscrsctp_close
    was called.

    Does anyone have any idea as to what this might be? Perhaps
    jnsctp needs updating in some way because of the windows updates.
    Maybe the pointers are now wrong because of the windows updates.

    On 26/01/2018 18:11, John Hemming wrote:

    I am using software based upon the bridge on a number of windows
    devices. It has recently started crashing the JVM on my
    development machine when I start doing a few things. I have it
    on two other machines and it has not crashed on either of these.

    a) I cannot find any log files which show why it is crashing.
    Does anyone have any suggestions as to how to get a log file for
    a JVM crash. I have tried looking for hs_err*.log and
    specifying a value for -XX:ErrorFile I am running the java
    command to do this.

    b) I am thinking that the main difference about my development
    machine is that I have applied Microsoft's patches for
    Spectre/Meltdown (I am not sure what patches, but some recent
    ones).

    This log is normally just before the crash:
    JVB 2018-01-24 10:28:16.493 INFO: [510]
    org.jitsi.videobridge.SctpConnection.log() CAT=stat
    sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec
    notification=SCTP_ASSOC_CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

    Does anyone have any hints as to where to look for this?

    I wonder if other people have had problems following updating
    for Meltdown/Spectre.

    I have some other Microsoft updates pending, but am not
    enthusiastic about applying them. I probably will, but I am
    very tempted to go through the linux learning curve to get away
    from Windows.

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

    --

    john.hemming.name <http://john.hemming.name>

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

    --

    john.hemming.name <http://john.hemming.name>

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev
    <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

--

john.hemming.name <http://john.hemming.name>


#9

Hey John,
I wrote those usrsctp instructions but afraid I never did anything with it
on windows so can't help you from experience there. That being said, I
think if you have the dll built, you just need to solve the general problem
of jni with a dll, so you should be able to google around for that.

-brian

···

On Wed, Jan 31, 2018 at 8:11 AM, John Hemming <john@hemming.email> wrote:

Thank you for this. It appears to give quite good instructions on how to
build an so library which I assume is for linux. However, I need to build
a DLL library for Windows64. I have not done any C or C++ coding for 20
years plus, but have downloaded and installed visual studio 2017 and
managed to build a usrsctp.dll file. I have also installed the C and
H(eader) files which I presume do the JNI magic.

Is there anything anywhere that you can suggest that makes the next steps
clearer. As it is a standard sort of thing I presume it should be quite
easy to resolve, but a pointer would be nice. (much that it is a pointer
that appears to be causing the problem).

On 31/01/2018 14:46, Damian Minkov wrote:

Hi,

https://github.com/jitsi/libjitsi/tree/master/src/native/sctp
There are few readme files there, explaining the building process.

Regards
damencho

On Jan 31, 2018 04:03, "John Hemming" <john@hemming.email> > <john@hemming.email> wrote:

I thought I would see if I could find a better solution than just not
closing scpt sockets. I think jnscpt.dll is based upon usrscpt (please
correct me if I am wrong). I tried using usrscpt_shutdown, that failed
with a link error so I looked at the dll and not all of the usrscpt
functions are exported.

Can anyone please tell me where I might find the code for creating
jnscpt.dll so that I might be able to export the shutdown function as well.

I assume that because scpt is included in linux this is not a linux
issue. (or if it is then it has been solved as part of linux rather than
usrscpt or anything like that).

However, for now I have reverted to not closing the sockets.

On 30/01/2018 15:07, John Hemming wrote:

I have made a bit of progress on this.

I discovered it was first a problem in ntdll.dll then I updated windows
and it was a problem with jvm.dll then I updated the java runtime to 162
and it still crashed.

Then after a bit of rummaging I stopped it running the native method
usrsctp_close which is linked to jnsctp.dll

    static void closeSocket(long ptr)
    {
        logger.info(Utils.getLogStart(null)+" native close of sctp
socket");
        if (Status.dontCloseUsrSCTPSocketsForNow==false) {
        usrsctp_close(ptr);
        }

        sockets.remove(Long.valueOf(ptr));
    }

As far as I can tell the JVM is no longer crashing. Interestingly it
appears that it crashed about 4-5 seconds after uscrsctp_close was called.

Does anyone have any idea as to what this might be? Perhaps jnsctp needs
updating in some way because of the windows updates.
Maybe the pointers are now wrong because of the windows updates.

On 26/01/2018 18:11, John Hemming wrote:

I am using software based upon the bridge on a number of windows
devices. It has recently started crashing the JVM on my development
machine when I start doing a few things. I have it on two other machines
and it has not crashed on either of these.

a) I cannot find any log files which show why it is crashing. Does
anyone have any suggestions as to how to get a log file for a JVM crash. I
have tried looking for hs_err*.log and specifying a value for
-XX:ErrorFile I am running the java command to do this.

b) I am thinking that the main difference about my development machine is
that I have applied Microsoft's patches for Spectre/Meltdown (I am not sure
what patches, but some recent ones).

This log is normally just before the crash:
JVB 2018-01-24 10:28:16.493 INFO: [510] org.jitsi.videobridge.SctpConnection.log()
CAT=stat sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_
id=d8aefd1b8b0b043e,endp_id=cc0bb4ec notification=SCTP_ASSOC_CHANGE
:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

Does anyone have any hints as to where to look for this?

I wonder if other people have had problems following updating for
Meltdown/Spectre.

I have some other Microsoft updates pending, but am not enthusiastic
about applying them. I probably will, but I am very tempted to go through
the linux learning curve to get away from Windows.

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

--

john.hemming.name

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

--

john.hemming.name

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

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

--

john.hemming.name

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


#10

It hasn't been as easy as I thought so I will leave it for now not closing sctp sockets. I think what is happening is that when the socket closes it clears down and releases memory, but from time to time something still comes in and now crashes it.

However, I may be entirely wrong and until I have a material amount of time to work on this I am going to leave it in what is not really an ideal state.

···

On 31/01/2018 18:09, Brian Baldino wrote:

Hey John,
I wrote those usrsctp instructions but afraid I never did anything with it on windows so can't help you from experience there. That being said, I think if you have the dll built, you just need to solve the general problem of jni with a dll, so you should be able to google around for that.

-brian

On Wed, Jan 31, 2018 at 8:11 AM, John Hemming <john@hemming.email > <mailto:john@hemming.email>> wrote:

    Thank you for this. It appears to give quite good instructions on
    how to build an so library which I assume is for linux. However,
    I need to build a DLL library for Windows64. I have not done any
    C or C++ coding for 20 years plus, but have downloaded and
    installed visual studio 2017 and managed to build a usrsctp.dll
    file. I have also installed the C and H(eader) files which I
    presume do the JNI magic.

    Is there anything anywhere that you can suggest that makes the
    next steps clearer. As it is a standard sort of thing I presume
    it should be quite easy to resolve, but a pointer would be nice.
    (much that it is a pointer that appears to be causing the problem).

    On 31/01/2018 14:46, Damian Minkov wrote:

    Hi,

    https://github.com/jitsi/libjitsi/tree/master/src/native/sctp
    <https://github.com/jitsi/libjitsi/tree/master/src/native/sctp>
    There are few readme files there, explaining the building process.

    Regards
    damencho

    On Jan 31, 2018 04:03, "John Hemming" <john@hemming.email> >> <mailto:john@hemming.email> wrote:

        I thought I would see if I could find a better solution than
        just not closing scpt sockets. I think jnscpt.dll is based
        upon usrscpt (please correct me if I am wrong). I tried
        using usrscpt_shutdown, that failed with a link error so I
        looked at the dll and not all of the usrscpt functions are
        exported.

        Can anyone please tell me where I might find the code for
        creating jnscpt.dll so that I might be able to export the
        shutdown function as well.

        I assume that because scpt is included in linux this is not a
        linux issue. (or if it is then it has been solved as part of
        linux rather than usrscpt or anything like that).

        However, for now I have reverted to not closing the sockets.

        On 30/01/2018 15:07, John Hemming wrote:

        I have made a bit of progress on this.

        I discovered it was first a problem in ntdll.dll then I
        updated windows and it was a problem with jvm.dll then I
        updated the java runtime to 162 and it still crashed.

        Then after a bit of rummaging I stopped it running the
        native method usrsctp_close which is linked to jnsctp.dll

         static void closeSocket(long ptr)
         {
        logger.info <http://logger.info>(Utils.getLogStart(null)+"
        native close of sctp socket");
         if (Status.dontCloseUsrSCTPSocketsForNow==false) {
         usrsctp_close(ptr);
         }

         sockets.remove(Long.valueOf(ptr));
         }

        As far as I can tell the JVM is no longer crashing.
        Interestingly it appears that it crashed about 4-5 seconds
        after uscrsctp_close was called.

        Does anyone have any idea as to what this might be? Perhaps
        jnsctp needs updating in some way because of the windows
        updates.
        Maybe the pointers are now wrong because of the windows updates.

        On 26/01/2018 18:11, John Hemming wrote:

        I am using software based upon the bridge on a number of
        windows devices. It has recently started crashing the JVM
        on my development machine when I start doing a few things.
        I have it on two other machines and it has not crashed on
        either of these.

        a) I cannot find any log files which show why it is
        crashing. Does anyone have any suggestions as to how to
        get a log file for a JVM crash. I have tried looking for
        hs_err*.log and specifying a value for -XX:ErrorFile I
        am running the java command to do this.

        b) I am thinking that the main difference about my
        development machine is that I have applied Microsoft's
        patches for Spectre/Meltdown (I am not sure what patches,
        but some recent ones).

        This log is normally just before the crash:
        JVB 2018-01-24 10:28:16.493 INFO: [510]
        org.jitsi.videobridge.SctpConnection.log() CAT=stat
        sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec
        notification=SCTP_ASSOC_CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

        Does anyone have any hints as to where to look for this?

        I wonder if other people have had problems following
        updating for Meltdown/Spectre.

        I have some other Microsoft updates pending, but am not
        enthusiastic about applying them. I probably will, but I
        am very tempted to go through the linux learning curve to
        get away from Windows.

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

        --

        john.hemming.name <http://john.hemming.name>

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

        --

        john.hemming.name <http://john.hemming.name>

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

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

    --

    john.hemming.name <http://john.hemming.name>

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev
    <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

--

john.hemming.name <http://john.hemming.name>


#11

This just reeks of a double-free from miles away.
Can you try modifying Sctp.closeSocket(ptr) to only call the JNI method if the passed ptr could be removed from the sockets map?

Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

On 1 Feb 2018, at 19:59, John Hemming <john@hemming.email> wrote:

It hasn't been as easy as I thought so I will leave it for now not closing sctp sockets. I think what is happening is that when the socket closes it clears down and releases memory, but from time to time something still comes in and now crashes it.

However, I may be entirely wrong and until I have a material amount of time to work on this I am going to leave it in what is not really an ideal state.

On 31/01/2018 18:09, Brian Baldino wrote:
Hey John,
I wrote those usrsctp instructions but afraid I never did anything with it on windows so can't help you from experience there. That being said, I think if you have the dll built, you just need to solve the general problem of jni with a dll, so you should be able to google around for that.

-brian

On Wed, Jan 31, 2018 at 8:11 AM, John Hemming <john@hemming.email> wrote:
Thank you for this. It appears to give quite good instructions on how to build an so library which I assume is for linux. However, I need to build a DLL library for Windows64. I have not done any C or C++ coding for 20 years plus, but have downloaded and installed visual studio 2017 and managed to build a usrsctp.dll file. I have also installed the C and H(eader) files which I presume do the JNI magic.

Is there anything anywhere that you can suggest that makes the next steps clearer. As it is a standard sort of thing I presume it should be quite easy to resolve, but a pointer would be nice. (much that it is a pointer that appears to be causing the problem).

On 31/01/2018 14:46, Damian Minkov wrote:
Hi,

https://github.com/jitsi/libjitsi/tree/master/src/native/sctp
There are few readme files there, explaining the building process.

Regards
damencho

On Jan 31, 2018 04:03, "John Hemming" <john@hemming.email> wrote:
I thought I would see if I could find a better solution than just not closing scpt sockets. I think jnscpt.dll is based upon usrscpt (please correct me if I am wrong). I tried using usrscpt_shutdown, that failed with a link error so I looked at the dll and not all of the usrscpt functions are exported.

Can anyone please tell me where I might find the code for creating jnscpt.dll so that I might be able to export the shutdown function as well.

I assume that because scpt is included in linux this is not a linux issue. (or if it is then it has been solved as part of linux rather than usrscpt or anything like that).
However, for now I have reverted to not closing the sockets.

On 30/01/2018 15:07, John Hemming wrote:
I have made a bit of progress on this.

I discovered it was first a problem in ntdll.dll then I updated windows and it was a problem with jvm.dll then I updated the java runtime to 162 and it still crashed.

Then after a bit of rummaging I stopped it running the native method usrsctp_close which is linked to jnsctp.dll
    static void closeSocket(long ptr)
    {
        logger.info(Utils.getLogStart(null)+" native close of sctp socket");
        if (Status.dontCloseUsrSCTPSocketsForNow==false) {
        usrsctp_close(ptr);
        }
    
        sockets.remove(Long.valueOf(ptr));
    }

As far as I can tell the JVM is no longer crashing. Interestingly it appears that it crashed about 4-5 seconds after uscrsctp_close was called.

Does anyone have any idea as to what this might be? Perhaps jnsctp needs updating in some way because of the windows updates.
Maybe the pointers are now wrong because of the windows updates.

On 26/01/2018 18:11, John Hemming wrote:
I am using software based upon the bridge on a number of windows devices. It has recently started crashing the JVM on my development machine when I start doing a few things. I have it on two other machines and it has not crashed on either of these.

a) I cannot find any log files which show why it is crashing. Does anyone have any suggestions as to how to get a log file for a JVM crash. I have tried looking for hs_err*.log and specifying a value for -XX:ErrorFile I am running the java command to do this.

b) I am thinking that the main difference about my development machine is that I have applied Microsoft's patches for Spectre/Meltdown (I am not sure what patches, but some recent ones).

This log is normally just before the crash:
JVB 2018-01-24 10:28:16.493 INFO: [510] org.jitsi.videobridge.SctpConnection.log() CAT=stat sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec notification=SCTP_ASSOC_CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

Does anyone have any hints as to where to look for this?

I wonder if other people have had problems following updating for Meltdown/Spectre.

I have some other Microsoft updates pending, but am not enthusiastic about applying them. I probably will, but I am very tempted to go through the linux learning curve to get away from Windows.

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

--

john.hemming.name

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

--

john.hemming.name

_______________________________________________
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

--

john.hemming.name

_______________________________________________
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

--

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


#12

Thanks for this suggestion. I have done the modification and it has not .... so far .... crashed in the IDE. When it crashes in the IDE it just stops.

When I run it as an executable jar it tells me it is not happy. I will experiment with that at some stage, but it does look like this is the cause. I will tell you if the fix goes wrong later if it goes wrong.

It is interesting if a double free used to not crash and now does crash. Still if it solves the problem I am a happy bunny. Bounce bounce bounce.

···

On 01/02/2018 13:56, Ingo Bauersachs wrote:

This just reeks of a double-free from miles away.
Can you try modifying Sctp.closeSocket(ptr) to only call the JNI method if the passed ptr could be removed from the sockets map?

Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

On 1 Feb 2018, at 19:59, John Hemming <john@hemming.email > <mailto:john@hemming.email>> wrote:

It hasn't been as easy as I thought so I will leave it for now not closing sctp sockets. I think what is happening is that when the socket closes it clears down and releases memory, but from time to time something still comes in and now crashes it.

However, I may be entirely wrong and until I have a material amount of time to work on this I am going to leave it in what is not really an ideal state.

On 31/01/2018 18:09, Brian Baldino wrote:

Hey John,
I wrote those usrsctp instructions but afraid I never did anything with it on windows so can't help you from experience there. That being said, I think if you have the dll built, you just need to solve the general problem of jni with a dll, so you should be able to google around for that.

-brian

On Wed, Jan 31, 2018 at 8:11 AM, John Hemming <john@hemming.email >>> <mailto:john@hemming.email>> wrote:

    Thank you for this. It appears to give quite good instructions
    on how to build an so library which I assume is for linux.
    However, I need to build a DLL library for Windows64. I have
    not done any C or C++ coding for 20 years plus, but have
    downloaded and installed visual studio 2017 and managed to build
    a usrsctp.dll file. I have also installed the C and H(eader)
    files which I presume do the JNI magic.

    Is there anything anywhere that you can suggest that makes the
    next steps clearer. As it is a standard sort of thing I presume
    it should be quite easy to resolve, but a pointer would be nice.
    (much that it is a pointer that appears to be causing the problem).

    On 31/01/2018 14:46, Damian Minkov wrote:

    Hi,

    https://github.com/jitsi/libjitsi/tree/master/src/native/sctp
    <https://github.com/jitsi/libjitsi/tree/master/src/native/sctp>
    There are few readme files there, explaining the building process.

    Regards
    damencho

    On Jan 31, 2018 04:03, "John Hemming" <john@hemming.email> >>>> <mailto:john@hemming.email> wrote:

        I thought I would see if I could find a better solution
        than just not closing scpt sockets. I think jnscpt.dll is
        based upon usrscpt (please correct me if I am wrong). I
        tried using usrscpt_shutdown, that failed with a link error
        so I looked at the dll and not all of the usrscpt functions
        are exported.

        Can anyone please tell me where I might find the code for
        creating jnscpt.dll so that I might be able to export the
        shutdown function as well.

        I assume that because scpt is included in linux this is not
        a linux issue. (or if it is then it has been solved as
        part of linux rather than usrscpt or anything like that).

        However, for now I have reverted to not closing the sockets.

        On 30/01/2018 15:07, John Hemming wrote:

        I have made a bit of progress on this.

        I discovered it was first a problem in ntdll.dll then I
        updated windows and it was a problem with jvm.dll then I
        updated the java runtime to 162 and it still crashed.

        Then after a bit of rummaging I stopped it running the
        native method usrsctp_close which is linked to jnsctp.dll

         static void closeSocket(long ptr)
         {
        logger.info <http://logger.info>(Utils.getLogStart(null)+"
        native close of sctp socket");
         if (Status.dontCloseUsrSCTPSocketsForNow==false) {
         usrsctp_close(ptr);
         }

        sockets.remove(Long.valueOf(ptr));
         }

        As far as I can tell the JVM is no longer crashing.
        Interestingly it appears that it crashed about 4-5 seconds
        after uscrsctp_close was called.

        Does anyone have any idea as to what this might be?
        Perhaps jnsctp needs updating in some way because of the
        windows updates.
        Maybe the pointers are now wrong because of the windows
        updates.

        On 26/01/2018 18:11, John Hemming wrote:

        I am using software based upon the bridge on a number of
        windows devices. It has recently started crashing the
        JVM on my development machine when I start doing a few
        things. I have it on two other machines and it has not
        crashed on either of these.

        a) I cannot find any log files which show why it is
        crashing. Does anyone have any suggestions as to how to
        get a log file for a JVM crash. I have tried looking for
        hs_err*.log and specifying a value for -XX:ErrorFile I am
        running the java command to do this.

        b) I am thinking that the main difference about my
        development machine is that I have applied Microsoft's
        patches for Spectre/Meltdown (I am not sure what patches,
        but some recent ones).

        This log is normally just before the crash:
        JVB 2018-01-24 10:28:16.493 INFO: [510]
        org.jitsi.videobridge.SctpConnection.log() CAT=stat
        sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec
        notification=SCTP_ASSOC_CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

        Does anyone have any hints as to where to look for this?

        I wonder if other people have had problems following
        updating for Meltdown/Spectre.

        I have some other Microsoft updates pending, but am not
        enthusiastic about applying them. I probably will, but
        I am very tempted to go through the linux learning curve
        to get away from Windows.

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

        --

        john.hemming.name <http://john.hemming.name>

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

        --

        john.hemming.name <http://john.hemming.name>

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

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

    --

    john.hemming.name <http://john.hemming.name>

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev
    <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

--

john.hemming.name <http://john.hemming.name>
_______________________________________________
dev mailing list
dev@jitsi.org <mailto: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

--

john.hemming.name <http://john.hemming.name>


#13

Further on this. Although this approach stopped the main part of the problem the JVM still crashed, but much more rarely. It appears that this occurs when data is sent on a pointer that has been freed. The JVB code does not have a problem with this as it simply ignores the situation, but it appears that something in the DLL tries to process it (this is a well informed guess).

Hence I have reverted to not freeing the pointer (closing the socket) and am instead tracking each pointer to see whether I can work out the circumstances in which this happens. I am also counting the number of times that the JVB code tries to close each socket and initially have found out the answer is two.

If I don't find a good solution to this a possible solution is to timeout the sockets and close them after a period of time. However, at least this enables me to get on with other things and have a reliable JVM.

I still think this is in some way related to Meltdown and/or Spectre and the Windows updates that came from there. I am not doing that complicated a thing with the SCTP data channel now that I wasn't doing before the update and this problem has only happened since the update.

On the other hand I don't know.

Obviously it shouldn't really be trying to close the socket twice, but I am not going to worry about that at the moment.

···

On 01/02/2018 14:46, John Hemming wrote:

Thanks for this suggestion. I have done the modification and it has not .... so far .... crashed in the IDE. When it crashes in the IDE it just stops.

When I run it as an executable jar it tells me it is not happy. I will experiment with that at some stage, but it does look like this is the cause. I will tell you if the fix goes wrong later if it goes wrong.

It is interesting if a double free used to not crash and now does crash. Still if it solves the problem I am a happy bunny. Bounce bounce bounce.

On 01/02/2018 13:56, Ingo Bauersachs wrote:

This just reeks of a double-free from miles away.
Can you try modifying Sctp.closeSocket(ptr) to only call the JNI method if the passed ptr could be removed from the sockets map?

Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

On 1 Feb 2018, at 19:59, John Hemming <john@hemming.email >> <mailto:john@hemming.email>> wrote:

It hasn't been as easy as I thought so I will leave it for now not closing sctp sockets. I think what is happening is that when the socket closes it clears down and releases memory, but from time to time something still comes in and now crashes it.

However, I may be entirely wrong and until I have a material amount of time to work on this I am going to leave it in what is not really an ideal state.

On 31/01/2018 18:09, Brian Baldino wrote:

Hey John,
I wrote those usrsctp instructions but afraid I never did anything with it on windows so can't help you from experience there. That being said, I think if you have the dll built, you just need to solve the general problem of jni with a dll, so you should be able to google around for that.

-brian

On Wed, Jan 31, 2018 at 8:11 AM, John Hemming <john@hemming.email >>>> <mailto:john@hemming.email>> wrote:

    Thank you for this. It appears to give quite good instructions
    on how to build an so library which I assume is for linux.
    However, I need to build a DLL library for Windows64. I have
    not done any C or C++ coding for 20 years plus, but have
    downloaded and installed visual studio 2017 and managed to
    build a usrsctp.dll file. I have also installed the C and
    H(eader) files which I presume do the JNI magic.

    Is there anything anywhere that you can suggest that makes the
    next steps clearer. As it is a standard sort of thing I presume
    it should be quite easy to resolve, but a pointer would be
    nice. (much that it is a pointer that appears to be causing the
    problem).

    On 31/01/2018 14:46, Damian Minkov wrote:

    Hi,

    https://github.com/jitsi/libjitsi/tree/master/src/native/sctp
    <https://github.com/jitsi/libjitsi/tree/master/src/native/sctp>
    There are few readme files there, explaining the building process.

    Regards
    damencho

    On Jan 31, 2018 04:03, "John Hemming" <john@hemming.email> >>>>> <mailto:john@hemming.email> wrote:

        I thought I would see if I could find a better solution
        than just not closing scpt sockets. I think jnscpt.dll
        is based upon usrscpt (please correct me if I am wrong).
        I tried using usrscpt_shutdown, that failed with a link
        error so I looked at the dll and not all of the usrscpt
        functions are exported.

        Can anyone please tell me where I might find the code for
        creating jnscpt.dll so that I might be able to export the
        shutdown function as well.

        I assume that because scpt is included in linux this is
        not a linux issue. (or if it is then it has been solved
        as part of linux rather than usrscpt or anything like that).

        However, for now I have reverted to not closing the sockets.

        On 30/01/2018 15:07, John Hemming wrote:

        I have made a bit of progress on this.

        I discovered it was first a problem in ntdll.dll then I
        updated windows and it was a problem with jvm.dll then I
        updated the java runtime to 162 and it still crashed.

        Then after a bit of rummaging I stopped it running the
        native method usrsctp_close which is linked to jnsctp.dll

         static void closeSocket(long ptr)
         {
        logger.info
        <http://logger.info>(Utils.getLogStart(null)+" native
        close of sctp socket");
         if (Status.dontCloseUsrSCTPSocketsForNow==false) {
         usrsctp_close(ptr);
         }

        sockets.remove(Long.valueOf(ptr));
         }

        As far as I can tell the JVM is no longer crashing.
        Interestingly it appears that it crashed about 4-5
        seconds after uscrsctp_close was called.

        Does anyone have any idea as to what this might be?
        Perhaps jnsctp needs updating in some way because of the
        windows updates.
        Maybe the pointers are now wrong because of the windows
        updates.

        On 26/01/2018 18:11, John Hemming wrote:

        I am using software based upon the bridge on a number of
        windows devices. It has recently started crashing the
        JVM on my development machine when I start doing a few
        things. I have it on two other machines and it has not
        crashed on either of these.

        a) I cannot find any log files which show why it is
        crashing. Does anyone have any suggestions as to how to
        get a log file for a JVM crash. I have tried looking
        for hs_err*.log and specifying a value for
        -XX:ErrorFile I am running the java command to do this.

        b) I am thinking that the main difference about my
        development machine is that I have applied Microsoft's
        patches for Spectre/Meltdown (I am not sure what
        patches, but some recent ones).

        This log is normally just before the crash:
        JVB 2018-01-24 10:28:16.493 INFO: [510]
        org.jitsi.videobridge.SctpConnection.log() CAT=stat
        sctp_notification,conf_id=30c6de8c34ec3069,content=data,ch_id=d8aefd1b8b0b043e,endp_id=cc0bb4ec
        notification=SCTP_ASSOC_CHANGE:assocId:0x3,COMM_LOST,(in/out)(1024/10),err0x0

        Does anyone have any hints as to where to look for this?

        I wonder if other people have had problems following
        updating for Meltdown/Spectre.

        I have some other Microsoft updates pending, but am not
        enthusiastic about applying them. I probably will, but
        I am very tempted to go through the linux learning curve
        to get away from Windows.

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

        --

        john.hemming.name <http://john.hemming.name>

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

        --

        john.hemming.name <http://john.hemming.name>

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

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

    --

    john.hemming.name <http://john.hemming.name>

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev
    <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

--

john.hemming.name <http://john.hemming.name>
_______________________________________________
dev mailing list
dev@jitsi.org <mailto: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

--

john.hemming.name <http://john.hemming.name>

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

--

john.hemming.name <http://john.hemming.name>