search

slomkowski / mumsi

SIP to Mumble gateway/bridge using PJSUA stack.
Apache License 2.0
41 stars 33 forks source link

only one way communication #13

Open pzi42 opened 8 years ago

pzi42 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

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 commented 8 years ago

which version of pjsip is used by mumsi?

pzi42 commented 8 years ago

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 commented 8 years ago

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

pzi42 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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:

slomkowski commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

You may modify Mumlib in following manner:

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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/slomkowski/mumsi/issues/13#issuecomment-205322112

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

pzi42 commented 8 years ago

ok I will try this, but where and how to set the frame length?.

streaps commented 8 years ago

see the comment from slomkowski:

https://github.com/slomkowski/mumsi/issues/13#issuecomment-205322112

slomkowski commented 8 years ago

@pzi42: did you achieve any results?

pzi42 commented 8 years ago

@streaps, @slomkowski thank you for your perfect help. mumsi is now working in the expected way.

pzi42 commented 8 years ago

Sorry for the late answer, wrote it, let my browser open and did some other things. So I forgot to send it.