[asterisk-users] SIP codec negotiation / manipulation

[Kevin Sandy]

On 3/17/2010 6:25 PM, Jeff Brower wrote:
> Steve-
> 
> On Wed, Mar 17, 2010 at 6:02 PM, Jeff Brower <jbrower at signalogic.com<mailto:jbrower at signalogic.com>> wrote:
> Steve-
> 
>> 2010/3/17 Vinícius Fontes <vinicius at canall.com.br<mailto:vinicius at canall.com.br>>
>>
>>> ----- "Kevin Sandy" <kevin.sandy at snohio.net<mailto: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
> 
> 



Well, I at least have more things to look into. A couple notes...

1. The provider's thought is that the reason audio is encoded
incorrectly is that our 200 OK with multiple codecs is confusing their
equipment. They believe that if we respond with only a single codec
(which can be any of their supported codecs, and can be different per
call), their equipment will handle it correctly and use the single
negotiated codec.

2. I had thought there was a limit in Asterisk that it would only detect
fax tones and send the re-invites for T38 if the call started as a more
or less uncompressed G711 call. I may be confusing that with a
limitation of some of the desktop soft-phone / fax clients I've used.


It seems that at the moment, the simplest solution is going to be to
setup our outbound SIP proxy as a peer in Asterisk (we're currently just
hitting it by using the proxy's IP in the Dial command). We can then
enable only a single codec for the outbound proxy while still allowing
customer phones to use either.

Unless... and I doubt it... there is some command or variable I can set
before calling Answer that will modify the list of codecs we send back.
That would be my ideal solution, as we could then look at the DID and
decide which codec we would like for this particular call based on which
codec that customer is using.