<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt><font size=+1>Steve-</font></tt>
<br><tt><font size=+1></font></tt>
<blockquote TYPE=CITE>
<div class="gmail_quote"><tt><font size=+1>On Wed, Mar 17, 2010 at 6:02
PM, Jeff Brower <span dir="ltr"><<a href="mailto:jbrower@signalogic.com">jbrower@signalogic.com</a>></span>
wrote:</font></tt>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><tt><font size=+1>Steve-</font></tt>
<div class="h5"><tt><font size=+1></font></tt>
<br><tt><font size=+1>> 2010/3/17 Vinícius Fontes <<a href="mailto:vinicius@canall.com.br">vinicius@canall.com.br</a>></font></tt>
<br><tt><font size=+1>></font></tt>
<br><tt><font size=+1>>> ----- "Kevin Sandy" <<a href="mailto:kevin.sandy@snohio.net">kevin.sandy@snohio.net</a>>
escreveu:</font></tt>
<br><tt><font size=+1>>></font></tt>
<br><tt><font size=+1>>> > We're having an odd issue with codec negotiation
from one of our SIP</font></tt>
<br><tt><font size=+1>>> > providers. Here's the basic situation.</font></tt>
<br><tt><font size=+1>>> ></font></tt>
<br><tt><font size=+1>>> > We receive an invite from them advertising support
for G711, G729, and</font></tt>
<br><tt><font size=+1>>> > G723. In our response, we send back that we
support G711 and G729. In</font></tt>
<br><tt><font size=+1>>> > about half the cases, this results in no problems,
with audio being</font></tt>
<br><tt><font size=+1>>> > encoded with G711. The other half of the time,
they send us a second</font></tt>
<br><tt><font size=+1>>> > invite requesting G729. However, they proceed
to send us a G711</font></tt>
<br><tt><font size=+1>>> > encoded audio stream...</font></tt>
<br><tt><font size=+1>>> ></font></tt>
<br><tt><font size=+1>>> > They have somewhat acknowledged the problem,
but their advice is for</font></tt>
<br><tt><font size=+1>>> > us to only accept a single codec in our 200
OK. We don't want to</font></tt>
<br><tt><font size=+1>>> > disable either; we have customers using G729,
so we'd like to avoid</font></tt>
<br><tt><font size=+1>>> > transcoding when possible, but we also do some
T38 faxing, which I</font></tt>
<br><tt><font size=+1>>> > believe requires G711 to start off.</font></tt>
<br><tt><font size=+1>>> ></font></tt>
<br><tt><font size=+1>>> > My first thought was to selectively force the
codec on inbound calls -</font></tt>
<br><tt><font size=+1>>> > if it is for a voice number, use 729, otherwise
711. However, I can't</font></tt>
<br><tt><font size=+1>>> > find any way of doing this within Asterisk.
(We do have an OpenSIPS</font></tt>
<br><tt><font size=+1>>> > server sitting between us and the provider,
and I could use OpenSIPS</font></tt>
<br><tt><font size=+1>>> > features to do this; however, right now the
OpenSIPS server is fairly</font></tt>
<br><tt><font size=+1>>> > dumb - it's only proxying traffic between us
and the provider and</font></tt>
<br><tt><font size=+1>>> > knows nothing about our specific DIDs.)</font></tt>
<br><tt><font size=+1>>> ></font></tt>
<br><tt><font size=+1>>> > A couple more details in case anyone has seen
a similar issue. The</font></tt>
<br><tt><font size=+1>>> > provider is Broadvox, and this issue only seems
to manifest on calls</font></tt>
<br><tt><font size=+1>>> > coming to them via Skype. They claim to not
have any direct link with</font></tt>
<br><tt><font size=+1>>> > Skype, but it seems odd that the problem would
be specific to Skype</font></tt>
<br><tt><font size=+1>>> > callers if the call is coming to Broadvox as
a standard PSTN call.</font></tt>
<br><tt><font size=+1>>> ></font></tt>
<br><tt><font size=+1>>> > Is there any way to do this? Am I totally missing
something and making</font></tt>
<br><tt><font size=+1>>> > a stupid mistake, or making the issue more complicated
than it needs</font></tt>
<br><tt><font size=+1>>> > to be?</font></tt>
<br><tt><font size=+1>>> ></font></tt>
<br><tt><font size=+1>>></font></tt>
<br><tt><font size=+1>>> If your only concern about using G711 is regarding
T38, go ahead and enable</font></tt>
<br><tt><font size=+1>>> G729 only. T38 doesn't need G711 at all.</font></tt>
<br><tt><font size=+1>>></font></tt>
<br><tt><font size=+1>>></font></tt>
<br><tt><font size=+1>> If your customers don't mind G729 then what is
said above is fine.</font></tt>
<br><tt><font size=+1>></font></tt>
<br><tt><font size=+1>> There will be a T.38 reinvite so it won't be G729
anymore. Canreinvite does</font></tt>
<br><tt><font size=+1>> not need to be set to yes for this to work in your
sip.conf either. It can</font></tt>
<br><tt><font size=+1>> be confusing but they are different types of reinvites.</font></tt>
<br><tt><font size=+1></font></tt> </div>
<tt><font size=+1>I don't see how this can work if Broadvox then sends
G711 anyway. I understand that to be the OP's root problem.</font></tt><tt><font size=+1></font></tt>
<p><tt><font color="#888888"><font size=+1>-Jeff</font></font></tt>
<br><tt><font size=+1></font></tt> </blockquote>
</div>
<tt><font size=+1>It doesn't matter what the codec is initially, if the
provider supports T.38 and you do too, a reinvite is sent changing whatever
codec over to T.38.</font></tt></blockquote>
<tt><font size=+1></font></tt><tt><font size=+1></font></tt>
<p><tt><font size=+1>I meant for the Broadvox voice output, but maybe your
suggestion works Ok and solves his problem.</font></tt><tt><font size=+1></font></tt>
<p><tt><font size=+1>-Jeff</font></tt>
<br><tt><font size=+1></font></tt> </html>