meetecho / asterisk-opus

Opus (transcoding) and VP8 (passthrough) support for Asterisk, needed for a better WebRTC integration
GNU General Public License v2.0
76 stars 86 forks source link

Codec bandwidth #2

Open sickpig opened 11 years ago

sickpig commented 11 years ago

Hi Lorenzo,

I'm the same Andrea that was bothering you about Opus bandwidth on asterisk-dev mailing list :) (see for reference http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg59507.html). Since Digium doesn't even want to talk about opus codec due to legal issues, I just decided to stop pestering the *-dev mailing list with opus related questions.

just to summarize: the opus leg of the call use 48KHz codec/decoder despite the fact that on the other leg we're using a 8KHz codec (e.g. g729, gsm etc. etc)

I've applied your patch to a pristine asterisk 11.4.0 source tree, a part a few solved hunks everything went well. I've set a sip peer just like that:

[1061]
type=peer username=1061 host=dynamic secret=1061 context=test disallow=all allow=opus hasiax =no hassip = yes encryption = no avpf = no icesupport = yes videosupport=no directmedia=no

I've used PhonerLite Beta to register using the above account. The test context is as simple as that:

[test] exten => _X.,1,Dial(SIP/mysipprovider/${EXTEN},20,Tt)

this is the a call console log

== Using SIP RTP CoS mark 5 -- Executing [3XXXXXXX@test:1] Dial("SIP/1061-00000023", "SIP/mysipprovider/3XXXXXXX,20,Tt") in new stack == Using SIP RTP CoS mark 5 -- Called SIP/mysipprovider/3XXXXXX [Opus] Created encoder #10 (48000->opus)[Opus] Created decoder #13 (opus->48000) -- SIP/mysipprovider-00000024 is ringing -- SIP/mysipprovider-00000024 answered SIP/1061-00000023

0x7fa100016620 -- Probation passed - setting RTP source address to 192.168.1.50:46933 0x2bf7f80 -- Probation passed - setting RTP source address to 85.158.217.167:14208 [2013-06-19 11:52:20] WARNING[30995][C-00000020]: res_rtp_asterisk.c:1477 __rtp_recvfrom: PJ ICE Rx error status code: 370400 'Bad Request'. == Spawn extension (test, 3XXXXXXXXX, 1) exited non-zero on SIP/1061-00000023' [Opus] Destroyed encoder #10 (48000->opus) [Opus] Destroyed decoder #13 (opus->48000)

here we have a screenshoot of the PhonerLIte (PB) beta networks tabs. As you can see we transmit 19Kbps, since that PB use opus@18Kbps, but we receive at 54Kbps.

opus

The env I was referring in the initial report posted to the asterisk-dev ml involved google-chrome/webrtc/JsSip as sip client and we saw in that case a transmission flow bandwidth equal to 54 Kbps. So it seems that setting a "fixed bitrate" as PB does solve the upstream problem, but do not solve the downstream one (from asterisk to the sip client).

Andrea

sickpig commented 11 years ago

I've tried also with a pristine copy of asterisk configuration files (make install sample), the only changes that I made are the one stated in the issue's first post, but still I got the same result.

Andrea

meetecho commented 11 years ago

The 19 vs 54 kbps is coherent with the rate they're likely using: I guess PhonerLite is configured to send 16kHz samples, while as also discussed on the Asterisk-dev mailing list Asterisk thinks the peer needs 48kHz, which is an average three times as much data.

Since the same scenario (8kHz on one side, opus on the other) works as expected in my (probably simpler) scenario, I guess there's something in either your extension or setup that causes the opus<->48000 instead of opus<->8000 transcoding path.

Have you already tried with Asterisk 11.1.2, just to be sure that's not the cause? Is IAX ever involved, even as a bridge/macro/whatever, in the call?

sickpig commented 11 years ago

I will try using an asterisk 11.1.2 (plus your patch) and report back.

in the mean time:

no IAX involved, no macros, nothing fancy just sample asterisk conf files that come with the tar.gz modified as shown in the first post.

Andrea

meetecho commented 11 years ago

Some more info that may help could be enabling SIP debug in Asterisk. that usually allows for some more details about what leads to a codec being chosen rather than another, for instance, so it may contain more details about what eventually leads to your scenario. I'm not sure about what other debug setting can be enabled specifically related to translation paths decisions, though...

sickpig commented 11 years ago

ok I will enable sip debug next time.

now I'm compiling Asterisk 11.1.2 and I'll test it shortly.

sickpig commented 11 years ago

Hi,

just tried with a freshly baked patched 11.1.2, unluckily same result. I've uploaded the console log with sip debug enabled and opus debug set to normal here:

http://opinioni.net/~sickpig/log.bz2

Andrea

sickpig commented 11 years ago

Hi Lorenzo

Did you get a chance to look at the log ?

Andrea

meetecho commented 11 years ago

I've only given it a quick glance, and found nothing strange about it. I don't have much time to do some testing right now, as soon as I can I'll try and replicate the scenario.

sickpig commented 11 years ago

Ok thanks Lorenzo. Take your time :)

andrew867 commented 11 years ago

As a note PhonerLite and Bira don't like Asterisk's ICE support (that's the error you're getting) set the config with icesupport=no or manually change icesupport=no in the [general] section of sip.conf.

Hope this helps! -Andrew

meetecho commented 11 years ago

Andrew,

that's weird, I don't seem to have any issue with PhonerLite with respect to ICE. I'm using the beta version of PhonerLite, though, which may have fixed something in that sense.