[Asterisk-Dev] Codec not negotiating

Michael Giagnocavo mgg-digium at atrevido.net
Mon Apr 4 12:37:35 MST 2005


>-----Original Message-----
>From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev->bounces at lists.digium.com] On Behalf Of Kevin P.
Fleming
>
>Jerris, Michael MI wrote:
>> http://bugs.digium.com/bug_view_page.php?bug_id=0003346 should address 
>> this issue, but there is not yet a patch with the implementation that 
>> was decided upon yet.
>
>While the patch for 3346 will possibly help with this situation, it 
>won't solve the problem completely. The issue is that according the 
>SIP/SDP RFCs, the receiver of an INVITE is free to choose any format 
>offered in the INVITE, regardless of the order in which they are presented.
>
>With that said, _most_ devices will honor the order in the SDP, and will 
>use the first offered format if they are able to do so. That is why 
>Asterisk will move the format of the calling channel to the top of the 
>list in the outgoing INVITE.
>
>The only way that this problem can be handled with 100% control is to 
>only offer the codec you want to use in the outgoing INVITE. For now, 
>that means using two different SIP peers for the outgoing calls.

If you look deeper in that patch, I realized that setting preferred codec is
almost useless for the situations I was trying to solve. That's why I
changed from PREFERRED codec to OVERRIDE codec. The override patch sends
ONLY the codec you choose. 

When placing calls to gateways and so on, not client devices, I think that
having full control and not allowing things up to "negotiation" to be a good
design. There's no reason to have to "negotiate" from a list of calls with
your gateway. At least, that'd be the case if you're using Asterisk as an
intelligent point and the gateway as just that: a piece of hardware.

-Michael





More information about the asterisk-dev mailing list