<div dir="ltr">2013/6/5 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Lorenzo and all,<div class="im"><br>
<br>
On 06/04/2013 05:31 PM, Lorenzo Miniero wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Dear James and all,<br>
</blockquote>
><br>
><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I managed to find out the cause of the issue. I simply forgot (mea culpa!) to add a couple of lines to the patch (which is why I couldn't replicate it in my setup, where the lines exist) which tells Asterisk which rate to use for the format. As you know, Opus always uses 48kHz, while the default in<br>
Asterisk is 8000: this caused wrong timestamp increase calculations on the non-Opus RTP leg, and hence the corrupt audio.<br>
<br>
I updated the patch on the repository. If you don't want to apply the patch again, just add these lines in the ast_format_rate method of format.c:<br>
<br>
/* Opus */<br>
case AST_FORMAT_OPUS:<br>
return 48000;<br>
<br>
and make/make install again. The easiest thing to do is put this as the last case before the default.<br>
<br>
Let me know if this fixes the issue,<br>
</blockquote>
<br></div>
as I already said this fix solve the issue we had.<br>
<br>
the tests we made are related to this configuration:<br>
<br>
(sip+opus) (iax/sip+g729)<br>
WebRTC -----------> Asterisk -----------------> pstn/mobile<br>
(A) (B)<br>
<br>
I know that there is no ad-hoc Opus configuration yet,<br>
but I'm trying to measure the bandwidth of the call opus leg (A).<br>
<br>
I've used iftop to get a rough measure, catching only udp<br>
packets. the iftop instance was executed on the same host<br>
where asterisk is running catching packets only on the net<br>
interface to which asterisk is bind to.<br>
<br>
While using opus the A leg bandwidth is something like 50/55 kb/s,<br>
from the webrtc client to the asterisk, while something along<br>
100kb/s from asterisk to client. is it normal?<br>
<br></blockquote><div><br></div><div style>Opus is conceived to be able to transparently switch rate during a call. In the code I made sure that the encoding would take note of the peer sampling rate, in order to cap it in Opus as well. This means that, if you're talking to a GSM/ulaw/g729 peer, Opus itself should be "capped" at 8kHz as there would be no need for a higher sampling rate to transport the audio.</div>
<div style><br></div><div style>What does the debug say in your case? When the encoder and decoder are created, do you get a opus->8000 and 8000->opus output, or is something else appearing? You can also check how big each encoded frame is, and how big each Opus incoming frame is on the other end, enabling a huge debug. I'll try to also add some more debug to check the rate of each individual packet, in case the capping I put in place is not working as expected. In 2.1 of <a href="http://www.ietf.org/id/draft-ietf-payload-rtp-opus-00.txt">http://www.ietf.org/id/draft-ietf-payload-rtp-opus-00.txt</a> there are indications about the typical bitrates at the supported sampling rates.</div>
<div style><br></div><div style>That said, I guess that other codec optimizations may be available that my integration does not make use of, so I guess I'll have to look into this as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
with ulaw I've got 85kb/s both from and to the asterisk server.<br>
<br>
another strange thing: when switching codec I need to restart asterisk<br>
to get a functioning calls otherwise callee (pstn end point) does not hear<br>
anything.<br>
<br></blockquote><div><br></div><div style>Restart Asterisk or restart the call? This sounds a bit extreme!</div><div style>Switching codecs shouldn't be an issue, though.</div><div style><br></div><div style>Lorenzo</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
this could be related to my setup/dialplan and having nothing to<br>
do with the patch in itself by the way, still it seems fishy though.<span class=""><font color="#888888"><br>
<br>
Andrea<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>