[Freeswitch-dev] Freeswitch chooses the first codec and ignores the rest

[Anthony Minessale]

I'd say its relatively hard.  Easier in master which is the only place it
would be possible to do but it requires some heavy mods to the media engine
and the rtp stack to track all the payloads and switch between them.

I do think there is another workaround if you set this profile param:

rtp-autofix-pt=true


That will detect when its not the one FS thinks and it will reinit the
codec.







On Thu, Sep 19, 2013 at 4:10 PM, Sam Russell <sam.h.russell at gmail.com>wrote:

> Thanks for the quick reply Anthony.
>
> Do you think this is a hard/easy thing to implement? I'm keen to
> contribute a bit to freeswitch, and this is functionality that I'd like to
> write some code for, and I can do what I like with our office PBX so I can
> test it here too.
>
>
> On Fri, Sep 20, 2013 at 8:56 AM, Anthony Minessale <
> anthony.minessale at gmail.com> wrote:
>
>> We currently only support one codec in 200OK  The workaround for this is
>> to only offer it PCMU so it has no choice.
>>
>>
>>
>> On Thu, Sep 19, 2013 at 2:52 PM, Sam Russell <sam.h.russell at gmail.com>wrote:
>>
>>> I've had a couple of calls recently that have been a little weird -
>>> here's the scenario:
>>>
>>> A (local freeswitch) sends invite with PCMU, PCMA as codecs
>>>
>>> B (foreign) sends 200 OK with PCMA, PCMU as codecs
>>>
>>> Freeswitch sees the response and sets audio codec to PCMA, but other
>>> end sends us PCMU (as it was our first choice in this case - sometimes
>>> they choose a random one that both of us support).
>>>
>>> RTP is fine with this - each packet refers to the # of the codec
>>> (either standard or a reference to an rtpmap from the SDP), but
>>> freeswitch doesn't like it - it forwards the PCMA from my soft phone,
>>> but the PCMU coming in from the foreign phone gets dropped by
>>> freeswitch and doesn't get forwarded onto my soft phone (packet trace
>>> shows freeswitch being the black hole).
>>>
>>> Debug output shows freeswitch setting the audio codec, and I suspect
>>> this means it then only accepts RTP with that codec, instead of
>>> handling all codecs that it offered in its invite.
>>>
>>> Is this expected behaviour? I went trawling through RFCs yesterday and
>>> nothing jumped out at me, and I'm seeing this on a couple of call
>>> managers - also sometimes the other end will send H263+ even though
>>> both ends offered H264 as preferred, and freeswitch drops this in the
>>> same manner. I think freeswitch should be handling all codecs that it
>>> offers, especially for video when it only does pass through, so
>>> spinning up instances of extra "codecs" shouldn't create much
>>> overhead.
>>>
>>> Sent from my iPhone
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-dev mailing list
>>> FreeSWITCH-dev at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>> http://www.freeswitch.org
>>>
>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>> Twitter: http://twitter.com/FreeSWITCH_wire
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> IRC: irc.freenode.net #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> googletalk:conf+888 at conference.freeswitch.org
>> pstn:+19193869900
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-dev mailing list
>> FreeSWITCH-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20130919/d0aa1747/attachment-0001.html