<div dir="ltr">2013/6/6 Andrea Suisani <span dir="ltr"><<a href="mailto:sickpig@opinioni.net" target="_blank">sickpig@opinioni.net</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 06/06/2013 09:49 AM, Andrea Suisani wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06/05/2013 09:08 PM, Andrea Suisani wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, June 5, 2013 5:53 pm, Lorenzo Miniero wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Andrea,<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[cut explanation of a maybe false theory]<br>
</blockquote></blockquote></blockquote>
<br>
[cut]<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The same scenario, in my setup, works fine: a browser calling a softphone<br>
using a narrowband codec (e.g., u-Law) is capped to 8kHz, opus<->8000.<br>
<br>
I guess the only difference between our scenarios (except for the several<br>
MACROS that are not in my test extension) is the protocol: in my<br>
extensions, only SIP is involved, and not IAX2. This may be what is<br>
causing<br>
the issue, as recently someone posted a similar problem on github:<br>
<br>
<a href="https://github.com/meetecho/asterisk-opus/issues/1#issuecomment-18926261" target="_blank">https://github.com/meetecho/<u></u>asterisk-opus/issues/1#<u></u>issuecomment-18926261</a><br>
<br>
Unfortunately I'm unfamiliar with IAX, so I don't know how codecs are<br>
negotiated and the related translation paths put in place for a call.<br>
</blockquote>
<br>
<br>
many thanks Lorenzo tomorrow I will try to test using SIP protocol<br>
on both call legs.<br>
</blockquote>
<br>
done. still 48kHz encoder/decoder. Unfortunately today I've no time<br>
to dig it, hope to get a few hours tomorrow. this is the console<br>
log (opus set debug huge)<br>
<br>
</blockquote>
<br></div>
did another two tests before switching to another task:<br>
<br>
1) force the second leg (asterisk ---> pstn/mobile) to use<br>
a gsm codec, still 48kHz<br>
<br>
2) all in the same lan (asterisk and webrtc clients)<br>
<br>
<br>
sip+opus sip+ulaw<br>
webrtc <----------> asterisk <------------> webrtc<br>
<br>
<br>
but still 48kHz<br>
<br></blockquote><div><br></div><div style>Scenarios 1 and 2 work fine for me, which makes me think there's something in your extensions flow that is causing the 48kHz reference. You may want to check which translation paths are put in place for the call, during the different stages of the call if the situation changes between the INVITE and the call itself.</div>
<div style><br></div><div style>That may help us understand what eventually leads to Asterisk requesting a Opus<->slin48 translation. Have you already checked the translation paths in general for Opus?</div><div style>
<br></div><div style> core show translation paths opus</div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3)<br>
sip+opus sip+opus<br>
webrtc <----------> asterisk <------------> webrtc<br>
<br>
no transcoding happening but from a quick iftop check<br>
it seems to take 50/55kbps (both up/downstream)<br>
<br>
<br>
maybe it's chrome fault. my version is Version 29.0.1521.3 dev.<br>
what's yours?<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div style>In this 3rd scenario, Opus is acting as passthrough, and so Asterisk does no transcoding. That's why the bandwidth consumption is lower than when capping to 48kHz, which is what's happening to you in the other scenarios. I have a bleeding edge Chrome installed as well so I doubt that's the issue.</div>
<div style><br></div><div style>Lorenzo</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Andrea<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>