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

[Sam Russell]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20130920/bbbc569c/attachment.html