<div dir="ltr">Hi Andrea,<br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/28 Andrea Suisani <span dir="ltr"><<a href="mailto:sickpig@opinioni.net" target="_blank">sickpig@opinioni.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Lorenzo,<br>
<br>
Firstly let me thank you for the work you're doing!<div class="im">
<br></div></blockquote><div><br></div><div style>Glad you're finding it useful!</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">
<div class="im">
On 05/27/2013 04:09 PM, Lorenzo Miniero wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear all,<br>
<br>
I've just published the patch on github:<br>
<br>
<a href="https://github.com/meetecho/asterisk-opus" target="_blank">https://github.com/meetecho/<u></u>asterisk-opus</a><br>
<br>
The README should be quite self explainatory, but if you need any additional info feel free to ask me.<br>
Any feedback will be more than welcome!<br>
</blockquote>
<br></div>
I've applied the patch to asterisk 11.3.0<br>
and it applies cleanly (modulo a few hunks here<br>
and there).<br>
<br>
Then I've tried to place a phone call from<br>
a chrome browser session (webrtc + jssip)<br>
through asterisk. the end point was a mobile<br>
phone. the callee leg of the call was terminated<br>
through a sip provider that use g729 or gms codecs.<br>
<br>
I've tested both type of transcoding.<br>
<br>
The sound was very choppy on callee side.<br>
whereas the sound on caller side was good.<br>
<br>
let me know if you are interested in any kind<br>
of call logs (opus set debug ...).<span class="HOEnZb"><font color="#888888"><br>
<br>
Andrea<br>
<br></font></span></blockquote><div><br></div><div style>Are you sure the choppy sound was not caused by the mobile connectivity of the mobile phone? even though I guess that was not the case, considering the caller side (the browser) was receiving good audio instead, origating from the mobile phone itself. Besides, have you verified Opus was actually used? I think that, as the patch is right now, Opus is not very high in the codec priority list when negotiating.</div>
<div style><br></div><div style>That said, I'm not sure what the cause of the issue could be. What ptime are the two peers using? What is the transcoding path as displayed on the Asterisk console? Does the same happen in other scenarios as well, e.g., the browser interacting with another browser, or a softphone using a different codec (e.g., speex) at different rates (e.g., 16kHz vs 8kHz)?</div>
<div style><br></div><div style>The 'opus set debug' command can be enabled when an encoder/decoder is created, to check whether decoding and encoding give any error, and the size of packets/samples that are extracted out of those processes. Try enabling a "normal" debug to see if any of error appears there (e.g., decoding errors that may result in corrupt outgoing audio) .</div>
<div style><br></div><div style>Lorenzo</div></div></div></div>