[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