Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Codec bandwidth #2

Open
sickpig opened this issue Jun 19, 2013 · 11 comments
Open

Codec bandwidth #2

sickpig opened this issue Jun 19, 2013 · 11 comments

Comments

@sickpig
Copy link

sickpig commented Jun 19, 2013

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/[email protected]/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
Copy link
Author

sickpig commented Jun 19, 2013

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
Copy link
Collaborator

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
Copy link
Author

sickpig commented Jun 19, 2013

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
Copy link
Collaborator

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
Copy link
Author

sickpig commented Jun 19, 2013

ok I will enable sip debug next time.

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

@sickpig
Copy link
Author

sickpig commented Jun 19, 2013

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
Copy link
Author

sickpig commented Jun 24, 2013

Hi Lorenzo

Did you get a chance to look at the log ?

Andrea

@meetecho
Copy link
Collaborator

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
Copy link
Author

sickpig commented Jun 25, 2013

Ok thanks Lorenzo. Take your time :)

@andrew867
Copy link

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
Copy link
Collaborator

meetecho commented Aug 4, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants