asterisk users - Mar 2010 - SIP codec negotiation / manipulation

We're having an odd issue with codec negotiation from one of our SIP
providers. Here's the basic situation.

We receive an invite from them advertising support for G711, G729, and G723. In
our response, we send back that we support G711 and G729. In about half the
cases, this results in no problems, with audio being encoded with G711. The
other half of the time, they send us a second invite requesting G729. However,
they proceed to send us a G711 encoded audio stream...

They have somewhat acknowledged the problem, but their advice is for us to only
accept a single codec in our 200 OK. We don't want to disable either; we
have customers using G729, so we'd like to avoid transcoding when possible,
but we also do some T38 faxing, which I believe requires G711 to start off.

My first thought was to selectively force the codec on inbound calls - if it is
for a voice number, use 729, otherwise 711. However, I can't find any way of
doing this within Asterisk. (We do have an OpenSIPS server sitting between us
and the provider, and I could use OpenSIPS features to do this; however, right
now the OpenSIPS server is fairly dumb - it's only proxying traffic between
us and the provider and knows nothing about our specific DIDs.)

A couple more details in case anyone has seen a similar issue. The provider is
Broadvox, and this issue only seems to manifest on calls coming to them via
Skype. They claim to not have any direct link with Skype, but it seems odd that
the problem would be specific to Skype callers if the call is coming to Broadvox
as a standard PSTN call.

Is there any way to do this? Am I totally missing something and making a stupid
mistake, or making the issue more complicated than it needs to be?

----- "Kevin Sandy" <kevin.sandy at snohio.net> escreveu:
> We're having an odd issue with codec negotiation from one of our SIP
> providers. Here's the basic situation.
> 
> We receive an invite from them advertising support for G711, G729, and
> G723. In our response, we send back that we support G711 and G729. In
> about half the cases, this results in no problems, with audio being
> encoded with G711. The other half of the time, they send us a second
> invite requesting G729. However, they proceed to send us a G711
> encoded audio stream...
> 
> They have somewhat acknowledged the problem, but their advice is for
> us to only accept a single codec in our 200 OK. We don't want to
> disable either; we have customers using G729, so we'd like to avoid
> transcoding when possible, but we also do some T38 faxing, which I
> believe requires G711 to start off.
> 
> My first thought was to selectively force the codec on inbound calls -
> if it is for a voice number, use 729, otherwise 711. However, I can't
> find any way of doing this within Asterisk. (We do have an OpenSIPS
> server sitting between us and the provider, and I could use OpenSIPS
> features to do this; however, right now the OpenSIPS server is fairly
> dumb - it's only proxying traffic between us and the provider and
> knows nothing about our specific DIDs.)
> 
> A couple more details in case anyone has seen a similar issue. The
> provider is Broadvox, and this issue only seems to manifest on calls
> coming to them via Skype. They claim to not have any direct link with
> Skype, but it seems odd that the problem would be specific to Skype
> callers if the call is coming to Broadvox as a standard PSTN call.
> 
> Is there any way to do this? Am I totally missing something and making
> a stupid mistake, or making the issue more complicated than it needs
> to be?
> 
If your only concern about using G711 is regarding T38, go ahead and enable G729
only. T38 doesn't need G711 at all.

Steve-

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

-Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20100317/f492bcb9/attachment.htm

17 mar 2010 kl. 16.37 skrev Kevin Sandy:
> We're having an odd issue with codec negotiation from one of our SIP
providers. Here's the basic situation.
> 
> We receive an invite from them advertising support for G711, G729, and
G723. In our response, we send back that we support G711 and G729. In about half
the cases, this results in no problems, with audio being encoded with G711. The
other half of the time, they send us a second invite requesting G729. However,
they proceed to send us a G711 encoded audio stream...
> 
> They have somewhat acknowledged the problem, but their advice is for us to
only accept a single codec in our 200 OK. We don't want to disable either;
we have customers using G729, so we'd like to avoid transcoding when
possible, but we also do some T38 faxing, which I believe requires G711 to start
off.
> 
> My first thought was to selectively force the codec on inbound calls - if
it is for a voice number, use 729, otherwise 711. However, I can't find any
way of doing this within Asterisk. (We do have an OpenSIPS server sitting
between us and the provider, and I could use OpenSIPS features to do this;
however, right now the OpenSIPS server is fairly dumb - it's only proxying
traffic between us and the provider and knows nothing about our specific DIDs.)
> 
> A couple more details in case anyone has seen a similar issue. The provider
is Broadvox, and this issue only seems to manifest on calls coming to them via
Skype. They claim to not have any direct link with Skype, but it seems odd that
the problem would be specific to Skype callers if the call is coming to Broadvox
as a standard PSTN call.
> 
> Is there any way to do this? Am I totally missing something and making a
stupid mistake, or making the issue more complicated than it needs to be?
> 
The problem here is that you have a proxy in between, so Asterisk can't have
separate peer configurations, since all the SIP messages are from the same IP
and thus the same peer. I have a branch that implements peer matching in this
specific configuration, which means that you can have different codec
configurations for different partners even though there's a proxy in front
of Asterisk.

https://origsvn.digium.com/svn/asterisk/team/oej/pinetree-1.4

Please try this branch and give feedback. There should be some docs in sip.conf
for the new "matchrule" setting.

/O