only one way communication

[pzi42]

mumsi seems running now without any problems. It seems. After a view seconds the communication from sip to murmur is dead. Communication from murmur to sip is functional. On my phone I can hear everything. My speech isn't avail on the murmur side. Waiting a few second an I'm back, speaking is possible. A few seconds more and I'm gone.

Any idea why I got this behaviour?

[slomkowski]

I had some problems with ordinary SIP client (Linphone, to be exact) when I was behind NAT. The connection was cancelled after ca. 30 s. They disappeared when I forwarded port UDP 5060 on my router. Can you try some other SIP client from the same machine and confirm whether it works?

After that, I would set log level to DEBUG (main.cpp, line 35) and look for communication.

[pzi42]

problems with NAT was my first thougt. So I tried mumsi, asterisk, murmur an mumble in the following environment:

• murmur on WindowsPC1 (Windows Version unkonown to me).
• mumble on WindowsPC2 (Windows Version unknown to me)
• asterisk on LinuxPC1 with CentOS 5.11
• mumsi on LinuxPC2 with CentOS 5.11

all PCs in the same Class-C Network.
DebugLog was aktiv, but I haven't found anything helping in the output.
Next test session will start on Monday. I will be able to geneare a kogfile and attach it to this issue. At the moment I can not test cause my environment (the two WindowsPCs) aren't available.

I tried mumsi on physical Machine1 under VBoxVM with CentOS7.2,and also with CentOS5.11 and also on bare metal with CentOS5.11. (LAN)
I tried mumsi on physical Machine2 under VBoxVM with CentOS7.2,and also with CentOS5.11 (NAT)

in every case I had the same problem. On my phone I can always hear what others are talking (without a break). But my own speech is transported for a few seconds (less than 10s) then it stops, after a few seconds (most often more than 10s) speech ist transported, then it stops and so on.

The mumble client shows a "red mouth" for a few seconds, then "black", a few seconds later "red" again an so on.

SIP Client, I use Linphone too, works perfect. Also phoner on Windows works perfect.

So next I will attach a logfile on Monday

[streaps]

which version of pjsip is used by mumsi?

[pzi42]

Excerpt from log

10:27:39.004 os_core_unix.c !pjlib 2.4.5 for POSIX initialized
10:27:39.007 sip_endpoint.c  .Creating endpoint instance...
10:27:39.007          pjlib  .select() I/O Queue created (0xa0ec010)
10:27:39.007 sip_endpoint.c  .Module "mod-msg-print" registered
10:27:39.007 sip_transport.  .Transport manager created.
10:27:39.008   pjsua_core.c  .PJSUA state changed: NULL --> CREATED
2016-04-01 10:27:39,024 [NOTICE] Pjsua: 10:27:39.024   pjsua_core.c  .pjsua version 2.4.5 for Linux-2.6.19.142/x86_64/glibc-2.5 initialized
2016-04-01 10:27:39,044 [NOTICE] Pjsua: 10:27:39.044    pjsua_acc.c  ....sip:53@192.168.1.3: registration success, status=200 (OK), will re-register in 185 seconds
2016-04-01 10:27:39,867 [NOTICE] mumlib.Transport: UDP is up.

I'm using Version 2.4.5

[slomkowski]

Can you attach log with DEBUG level? The log you have pasted is on NOTICE. I might spot something.

[pzi42]

I made more tests and I now know what the problem is.

murmur.ini

# Maximum bandwidth (in bits per second) clients are allowed
# to send speech at.
bandwidth=16000

It seems mumsi has problems with limited bandwith. After removing the bandwith limit the communication is working fine.

Is it possible to limit the bandwith using mumsi?
In an environment with mobile devices it may be essential to limit the bandwith.

[slomkowski]

The problem with SIP is that it transmits voice constantly, even when people are not talking (you can see that mumsi icon in Mumble client is always active during SIP call). To enable this, noise gate has to be implemented.

I assumed that voice frame is sent every 20 ms to Murmur. You can experiment with different frame lengths changing 20 to other value allowed by Mumble (10, 20, 60 if I'm not mistaken) in file https://github.com/slomkowski/mumsi/blob/master/PjsuaCommunicator.cpp#L75.

I'm currently at work, so I cannot test it now.

[streaps]

Why not set the Opus encoder bitrate?

http://www.opus-codec.org/docs/html_api/group__encoderctls.html

If I understand it correctly, mumsi doesn't have a bitrate setting. But I think it could be hardcoded in mumlib as a workaround.

https://github.com/slomkowski/mumlib/search?utf8=%E2%9C%93&q=opus_encoder_ctl&type=Code

[slomkowski]

AFAIK Mumble defines only one valid bitrate for Opus: 48 kHz (https://github.com/mumble-voip/mumble/blob/13e494c60beb20748eeb8be126b27e1226d168c8/src/mumble/Audio.h#L43).

[streaps]

Samplerate and bitrate are two different things.

Mumble defines only one valid bitrate samplerate for Opus, but in the Mumble client I can set the bitrate from 8 kb/s to 96 kb/s.

Opus supports:

• Bitrates from 6 kb/s to 510 kb/s
• Sampling rates from 8 kHz (narrowband) to 48 kHz (fullband)
• Frame sizes from 2.5 ms to 60 ms
• Constant bitrate (CBR) and variable bitrate (VBR)

[slomkowski]

Oops, my bad. The only thing I set for Opus encoder is disabling variable bitrate which is identical with original client. I haven't given it any second thought.

Are you willing to perform some experiments which will determine the acceptable bitrate in your setup?

[pzi42]

yes, I'm really willing to perform some experiment to determine an acceptable bitrate.
So tell me what do do, if I'm able to do it, I will do it.

[slomkowski]

You may modify Mumlib in following manner:

• after line https://github.com/slomkowski/mumlib/blob/master/src/Audio.cpp#L25 put code like this:

error = opus_encoder_ctl(encoder, OPUS_SET_BITRATE(BITRATE));
if (error != OPUS_OK) {
        throw AudioException((boost::format("failed to set encoder bitrate to %d: %s") % BITRATE % opus_strerror(error)).str());
}

You can experiment with different BITRATE setting.

I measured bitrate in default configuration on my machine (Murmur and mumsi on localhost, SIP from external provider) using following command:

iftop -i lo -n -l -P

Trafic from mumsi to Murmur was ca 64 kB/s. In Mumble client you can set the bitrate to as low as 8 kB/s, but I cannot say how it affects the sound quality.

[pzi42]

Thanks fpr the help. I tested with multible Bitrates. wir BITRATE=16000 iftop show me about 20kb/s transmission to murmur. So we have the effect "one way communication" continue. There ist longer "speaking" and shorter dropouts than with 64kb/s.

Reducing Bitrate to 8000 make no differenc in transferrate. mumsi is ongoing with a transmission on about 20kb/s.

So is there another place in the code where I have to change something for reducing bitrate to 8000kb/s. If we set bandwith to 16000 in murmur, mumble sets own transmission to 8000kb/s. so this ist what I want do do with mumsi. (automatic not needed).

[streaps]

Besides the raw Opus audio data (which is 8 kb/s), there is also the protocol overhead which depends on the frame length.

60 ms: 7.8 kb/s overhead
40 ms: 10.1 kb/s
20 ms: 14.8 kb/s
10 ms: 28.8 kb/s

see https://wiki.mumble.info/wiki/FAQ/English#What_are_the_bandwidth_requirements.3F

If you set the frame length to 60 ms, it might be working (8kb/s + 7.8 kb/s = 15.8 kb/s).
see #13 (comment)

I guess the mumble client automatically adjusts bitrate and frame length.